gwt exception handling
Ian Springer
ian.springer at redhat.com
Mon Dec 6 18:52:06 UTC 2010
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 at redhat.com
More information about the rhq-devel
mailing list