Hi Bob and all,

While playing around with deRPC, I found an inconsistent behavior that makes
me suspect it is a bug. But before filing any issue, I want to get your
feedback.
This simple test checks RuntimeException handling between RPC 1 and RPC 2.
it is straightforward :

Server side
---------------------
public class MyServiceImpl extends RpcServlet implements
        MyService {

    public Something findSomething(String name)  {
        // IncorrectNameException inherits from RuntimeException
        if (name.isEmpty()) throw new IncorrectNameException("nom
incorrect");
        return something;
    }

Client Side
---------------
AsyncCallback<Something> callback = new AsyncCallback<Something>() {

            @Override
            public void onSuccess(Something result) {
                Window.alert("great"...);
            }

            @Override
            public void onFailure(Throwable caught) {

                *if (caught instanceof IncorrectNameException) {*

                   *// Called in DevMode*
                   Window.alert("the name is incorrect : \n Exception =" +
caught.getClass());
                }
                else {
                   * // Called in ProdMode*
                    Window.alert("unexpected error occurred " +
caught.getClass().toString());
                }
            }

rpc.findSomething("",callback);
------------
Trying to get insight on how to solve this problem I traced the payloads
with -DdumpPayload :
->In DevMode
T~Lcom.dng.derpc.client.IncorrectNameException~I1~"19~java.lang.Throwable~"13~detailMessage~"13~Incorrect
Name~

->In Prod Mode
Error 500 The call failed on the server; see server log for details
StatusCodeException  (this exception should be InvocationException, right?)

This confirms that in DevMode the runtime exceptions are propagated and
serialized and not in ProdMode.

Getting back to RPC 1.0 makes the same test consistent across the two modes,
the usual InvocationException is thrown in Dev and Prod Mode.

I would be happy to learn that RPC 2 propagates properly the server Runtime
exceptions (instead of this ugly error 500 msg that lost our stacktrace) ...
:-)

Thought ?

Sami

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to