How to handle a Python server-side Exception in GWT client code?

99 views
Skip to first unread message

Carl

unread,
Apr 11, 2013, 4:32:14 AM4/11/13
to google-we...@googlegroups.com
I'm using AsyncCallback<String>() to handle JSON replies from my Python-backed server.

If the server throws a custom exception, NotUniqueException my client code AsyncCallback.onFailure(Throwable caught) is called.

In the GWT client code, how do I gain access to NotUniqueException? Or at least know that this type of exception was thrown? 

Carl

unread,
Apr 11, 2013, 5:39:16 AM4/11/13
to google-we...@googlegroups.com
One less layer...

I'm using RequestBuilder's sendRequest and handling errors in that call's onResponseReceived(Request req, Response resp)

That function still has flatten the server's exception to resp.getStatusCode() of 500 and resp.getStatusText() of "INTERNAL SERVER ERROR".

What approach could I take to get access to the server's raised NotUniqueException ?

Ümit Seren

unread,
Apr 11, 2013, 11:11:35 AM4/11/13
to google-we...@googlegroups.com
You can't just simply handle server side exception in GWT especially when you deal with non-JAVA backends (GWT RPC/RequestFactory have ways to translate server side exceptions to the client side exceptions). 
So you have to roll your own exception translation. 

You can catch exceptions in your python application sever and then use a custom response code (or re-use response code 500) together with specific statustext (maybe a JSON response containing the server side message of the exception and the type). 
On the GWT client you have to check the statuscode and the statustext (parse the JSON) and raise a GWT exception or handle it directly there. 

Carl Roach

unread,
Apr 11, 2013, 11:26:23 AM4/11/13
to google-we...@googlegroups.com
thanks Ümit. That's the only approach I could think of too. I think it can be wrapped nicely but thought I'd check there wasn't a smarter technique available (it's all just data after all).

thanks for boosting my confidence that this wasn't such a blunt instruction.


--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/wd7flaenDZo/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Carl Roach

unread,
Apr 16, 2013, 11:29:45 AM4/16/13
to google-we...@googlegroups.com
After some investigation this is an approach I've found...

In my python code:
     raise HTTP(409, "Team name already exists.", exception="team-name-not-unique", name=name, cap=cap)

The 400 codes are for client errors and 409 is a "CONFLICT" (e.g., a conflict for a resource - in my case for an attempt to name a team the same as another team; cap is just included to illustrate multiple parameters).
The named parameters (name & cap) are added to the response's headers.

In GWT create an exception class TeamNameNotUniqueException.java based on Exception with a CONST to take a name & cap and a getName() & getCap() methods.

In the onResponseReceived() of RequestBuilder you can check response.getStatusCode() == Response.SC_CONFLICT

String type = response.getHeader("exception");
if (type.equals("team-name-not-unique")) {
    asyncCallback.onFailure(new TeamNameNotUniqueException(response.getHeader("name"),
                                Integer.parseInt(response.getHeader("cap"))));

Put all this in a try/catch block to handle errors and so we can otherwise assume the headers are correct.
One can add on additional tests again "type" for using alternative exceptions.

Downsides:
- this approach does place all such exception classes into one file which doesn't keep code splitting streamlined. At least the exception classes are small.
- the file has to be edited each time a new exception class is required by an app.
Reply all
Reply to author
Forward
0 new messages