1 Reply Latest reply on Sep 26, 2011 5:55 PM by Mike Brock

    Error handling

    fvitorc Newbie



      I am new to Errai. Just started writing some code to check its functionalities a couple of weeks ago.

      One thing that I just couldn't figure it out, is how errors are handled when trying to send a message from the client to the server.


      I've tried to simulate every possible error to get caught in the errorsHandledBy handler, but to no avail:


      1) Manually stopping the server, and then sending a message from the client.

      2) Suddenly start responding with 403, 404, 500, etc status, and then send a message from the client.

      3) Specifying an unknown service name to the toSubject method.

      4) Throwing exceptions from the services.


      Cases 1 and 3 are handled immediately by the LogAdapter. Case 2 is handled by the LogAdapter when the current push connection is closed and a new one is made (I am using DefaultBlockingServlet. Don't know how would that work with real push servlet implementations). Case 4 is also handled immediately by the LogAdapter, but I have already discovered that it is only supposed to work with Errai RPC.


      Does anyone knows what kind of error is passed to the errorsHandledBy handler?


      If you take a look at the default GWT RPC, it provides an InvocationException when it can't reach the service implementation (cases 1 and 2) or when an undeclared exception is thrown by the service. It also provides an IncompatibleRemoteServiceException when there is an incompatibility between the client and the server (may fit case 3 if you refactor the services names, but don't recompile the client).


      I am using Errai 1.3.0-CR1.




        • 1. Re: Error handling
          Mike Brock Master

          Yes. I have identified problems in some of our recent refactorings that have broken error handling on the client-side. I have now pushed a set of fixes out in our lastest 1.3.0-SNAPSHOT if you want to give them a try.


          It should address 1, 2, and 3. Now concern 4 is supported, but the exceptions must be exposed to the bus via normal serialization rules.


          Transport related exceptions should return TransportIOException.