Inherited exceptions in GWT-RPC

[Ryan]

My understanding is that in GWT-RPC, if a service throws an exception
declared in the signature, then GWT will report that exception back to
the client as-is. If it's any other exception that's thrown, then GWT
wraps it in an InvocationException.

I have a hierarchy of exceptions that could get thrown in my
application. For example:

class AException extends RuntimeException {}
class BException extends AException {}
class CException extends AException {}

If I declare AException in the client, and throw it in the server,
then the onFailure() method gets called with AException as expected.
However, if I declare AException in the client, but throw either of
the two child classes in the server, GWT wraps it in an
InvocationException.

What is the best way to intercept ALL the child exceptions? The only
thing I can see so far is declaring each possible child exception in
the service signature, but that seems very brittle to me.

Thanks,
Ryan

[Paul Robinson]

You shouldn't need to do anything. It should work as you thought. That is, you can throw any subclass of the declared exception(s).

Is there something about BException and CException that stops them from being gwt-serializable?

Alternatively, maybe it's because AException extends RuntimeException, and is therefore not a checked exception. It could be that, being an unchecked exception, GWT silently drops it (or rather, its subclasses) from the list of exceptions to expect.

Try "AException extends Exception" instead.

HTH
Paul

[Ryan]

On Aug 26, 12:51 am, Paul Robinson <ukcue...@gmail.com> wrote:
> You shouldn't need to do anything. It should work as you thought. That is, you can throw any subclass of the declared exception(s).
>
> Is there something about BException and CException that stops them from being gwt-serializable?

No, and in fact, if I declare them explicitly, then GWT throws them as-
is, rather than wrapping them in InvocationException.

> Alternatively, maybe it's because AException extends RuntimeException, and is therefore not a checked exception. It could be that, being an unchecked exception, GWT silently drops it (or rather, its subclasses) from the list of exceptions to expect.
>
> Try "AException extends Exception" instead.

That's what I'm afraid of. It looks like GWT will only allow declared
exceptions, and not subclasses. I don't want to extend Exception,
because it means the Java compiler will force me to handle the
exception explicitly:

try {
service.remoteMethodThatThrowsException( ... , new
AsyncCallback<Void>() {
@Override
public void onFailure( Throwable caught ) { ... }

@Override
public void onSuccess( Void result ) {...}
} );
} catch (Exception e) {}

That sort of defeats the purpose for handling the exception in the
onFailure() method to begin with.

[Colin Alworth]

On Thursday, August 25, 2011 3:09:22 PM UTC-5, Ryan wrote:

However, if I declare AException in the client, but throw either of
the two child classes in the server, GWT wraps it in an
InvocationException.

This is the key to your issue - if the client can't de-serialize it (because the code only exists where the server can see it, not the client), it can't allow it to be thrown to the client.

Unless I've misunderstood, and all three are declared in the client package, but only AException is declared as part of the RPC method signature. If that is the case, this should work as you expect. A few other things could B, C from being available to be deserialized, such as being blacklisted in your module file, or not having default (i.e. no-arg) constructors, things that would affect any other DTO expected to work with RPC.

[Ryan]

Thanks, Colin. I'll double-check my module file and make sure the
exceptions are being included for the GWT compiler. That may be the
reason they're being missed.