Adding the throws clauses is the quick fix, but it doesn't address the
problem of the coregui code having to do String parsing to figure out
the root cause, since the root cause has been converted to a String and
stuck into the message of the wrapping RuntimeException:
throw new RuntimeException(ThrowableUtils.getAllExceptions(e));
For example, here's what I have to resort to in
UsersDataSource.executeAdd():
String message = caught.getMessage();
if (message != null &&
message.contains("javax.persistence.EntityExistsException")) {
Map<String, String> errorMessages = new
HashMap<String, String>();
errorMessages.put(Field.NAME, "A user named [" +
newSubject.getName() + "] already exists.");
sendValidationErrorResponse(request, response,
errorMessages);
} else {
throw new RuntimeException(caught);
}
Notice the message.contains(...) check.
It would be much preferred for either the SLSB method of the async impl
class to throw a strongly typed exception, e.g.:
throw new org.rhq.core.domain.exception.EntityExistsException("A
subject named " + subjectName + " already exists.");
then the coregui code would not have to resort to parsing the exception
message - it could instead use an instanceof check, e.g.:
if (caught instanceof
org.rhq.core.domain.exception.EntityExistsException) {
Map<String, String> errorMessages = new
HashMap<String, String>();
errorMessages.put(Field.NAME, "A user named [" +
newSubject.getName() + "] already exists.");
sendValidationErrorResponse(request, response,
errorMessages);
} else {
throw new RuntimeException(caught);
}
cleaner and more stable maintenance-wise.
Btw, I'd use "throws RuntimeException", rather than "throws
Exception",
in the async impl class methods, since it's more specific.
On 12/06/2010 09:27 AM, John Mazzitelli wrote:
You need a slight clarification:
> If I understand Mazz correctly, as long as we declare that the method
> throws Exception - even if we only ever throw RuntimeException - things
> will "just work".
If you mean to say explicitly "java.lang.RuntimeException", then yes,
this is correct (e.g. "throw new java.lang.RuntimeException()").
However, it can't be any ol' exception derived from RuntimeException.
Even if its an exception that extends RuntimeException, if that
exception class isn't available to the GWT client, it still won't work.
So, IllegalArgumentException is fine - because its available to the
GWT client, but "InvalidAlertDefinitionException" (which is one of
ours), is not fine because even though its a RuntimeException, it is
not available to the GWT client since its only in server/jar. Same
goes for EJBException - its a RuntimeException but its not available
to the GWT client since it knows nothing about javax.ejb.*.
--
Ian Springer
Principal Software Developer
JBoss Operations Network
Red Hat
ian.springer(a)redhat.com