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