2 Replies Latest reply on Jun 14, 2006 6:23 PM by andrew vine

    Seam AJax Remoting and throwing of exceptions

    andrew vine Newbie

      Hi, a quick question

      A nice feature of dwr is that exceptions thrown from remote methods are passed as the second argument in the call back function.

      Does the ajax remoting code cuurently cater for this?


        • 1. Re: Seam AJax Remoting and throwing of exceptions
          Shane Bryzak Master

          Not yet, I've been trying to think of an elegant way of handling exceptions. In a lot (most?) of cases you won't want to return a stack trace to the client; instead a simple error code/message would be more useful. Whether this is something that is done client side or server side I'm not sure. I'm leaning toward server side because it would be nice to support I18N for error messaging, and this way your error messages could be stored in a message bundle resource.

          As for how the message is handled on the client, I was thinking something along the lines of allowing exception handlers to be registered at the method level, e.g. Seam.Remoting.registerExceptionHandler("componentName", "componentMethod", handlerMethod). Then your exception handler could do something graceful, like display a 'Sorry the customer details could not be retrieved at this time' message, etc.

          • 2. Re: Seam AJax Remoting and throwing of exceptions
            andrew vine Newbie

            Ok. It is funky idea to have a seperatate callback on error. I think MochiKit allowed you to do this. I don't understand completely what you want to do but what is important to me is that I could still provide a message with my exception and have that displayed to the user. eg..

            public BigDecimal getBalance(String accountNumber) throws MyRemoteException
            // not a valid account
            throw new MyRemoteException("You have entered an invalid account number.");
            // account closed
            throw new MyRemoteException("This account is closed.");

            It may be cleaner to pass error codes back in the exception and then match that to a localized message but I don't want to be forced to do that.