May 12
15

Global Exception Handling in GWT

2 Comments

gwt development

Ghosts in the Machine – When Exceptions Happen

There are times when your GWT application will simply do wild and crazy things and you have no idea why they are happening.  Or even worse, it will not do things that it is supposed to!  You can spend hours upon hours of pulling out your hair trying to trace down the exact area that is failing without any luck.  There is also the dreaded “It works in dev mode, but not when it is running in web mode!”  Just thinking about that makes me cringe.  Many times it comes down to knowing the tricks for exception handling in gwt.

If you work on any production grade application written in GWT, you will come across something like this.  It is almost inevitable, but if you are armed with just a few simple tricks, you can save hours if not days of frustration and rewriting of code.

For me, I first encountered this brain buster when I was trying to add a new library into my project.  I thought I had followed the instructions to the “T”, and I had…almost.   I had done the obligatory “inheriting the external module” in my project.gwt.xml file (this tells GWT that there is an external source of code to go look for) and had even properly initialized this new library.  Even though these had been correctly done, I still wasn’t getting the correct behavior.  After what seemed like a lifetime of poking around inside the new library’s code (and almost ditching it), I realized that it was my own fault because I was not using one of the classes quite right.

What was actually happening?  Down in the bowls of this new library, there was a RuntimeException being thrown due to my incorrect usage.  At first glance this may seem like I should have been able to catch this rather easily, but here is the rest of the story.  In the method call, there was a command scheduled to run at a later time and during that command’s execution the Exception was being thrown.  I couldn’t just wrap my method call with a try-catch block and log a stack trace because it was running at some later, undefined time.  So what’s the answer?  How can you track this down the easy way?

Global Exception Handling

The answer is to register a global exception handler in your entry point class.  Ok, ok, technically it doesn’t have to be in the EntryPoint class, but that is a good place to put it.

The basic concept is that if anything happens to go wrong somewhere at sometime during the execution of your application, and there are no handlers to take care of Exceptions that pop up, this particular piece of code will get called and handle it.  Now theoretically, there isn’t really much you can do typically at a global scale to handle an arbitrary Exception, so this is usually a good place to put some sort of logging and message the user that something has gone wrong.

No matter what your production code will eventually do, this is a great place to put some debug code to give you a glimpse into your development woes.  You can find some other good ideas for this at the GWT Developer site.

Registering a Global Exception Handler

When I discovered this little trick, I couldn’t believe just how easy it is to register the handler.  It felt like it was just a tad bit too easy and I had to be missing something.  It is so simple in fact that when I make new projects, one of the first things I do right after I cut the generated code is to add a Global Exception Handler right at the beginning of my EntryPoint class.  Here is my typical “debugger handler” that I add to save hours of grief and frustration.

 

Notice on line 4 and 5, I have put two types of logging.  Line 4 will actually display a browser Alert box to tell me what is going on and line 5 will print out a stack trace.  I may switch back and forth between these from time to time because I may not want to see the Alert box.  Keep in mind though, there is no console when you are running in web mode and that Alert box is the only indication that something went wrong.

Keep this little trick in your back pocket for the next time your application is behaving in odd ways and you will save tons of time and frustration.

 

External Sources

setUncaughtExceptionHandler JavaDoc

Other GWT Developer Articles

Google I/O - Best Practices for Architecting GWT App

This entry was posted on May 15, 2012 at 2:57 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Posted in GWT Development by Jeff Richley 2 Comments

2 Responses to "Global Exception Handling in GWT"

  • Yannis Bres says:
    May 17, 2012 at 12:11 pm

    Hi and thanks for all these helpful posts !

    Indeed, all GWT programs should better start by registering a default exception handler.

    However, note that, as reported in Issue 1617 [ http://code.google.com/p/google-web-toolkit/issues/detail?id=1617 ], the default exception handler will only be effective at the end of the current event loop processing (my guess) : if you have a complex onModuleLoad() method and something wrong happens there, the default exception handler won’t be called. As such, the remaining of the onModuleLoad() code should better be run in a deferred command.

    An additional advice could be to use Fred Sauer’s logging library, gwt-log [ http://code.google.com/p/gwt-log/ ], which provides a default exception handler that should suits most needs (uncaught exceptions should only happen in dev env, shouldn’t they ? ;-) ).

    I happen to have a parent entry point, shared by several GWT projects, which just sets up this default exception handler :

    package …;

    import com.allen_sauer.gwt.log.client.Log;
    import com.google.gwt.core.client.EntryPoint;
    import com.google.gwt.core.client.Scheduler;
    import com.google.gwt.core.client.Scheduler.ScheduledCommand;

    /**
    * The parent class of GWT Application Entry Points.
    */
    public abstract class AbstractEntryPoint
    implements EntryPoint
    {
    @Override
    public final void onModuleLoad()
    {
    // see GWT Issue 1617: UncaughtExceptionHandler not triggered for exceptions occurring in onModuleLoad() [http://code.google.com/p/google-web-toolkit/issues/detail?id=1617]
    Log.setUncaughtExceptionHandler();

    Scheduler.get()
    .scheduleDeferred( new ScheduledCommand()
    {
    @Override
    public final void execute()
    {
    doOnModuleLoad();
    }
    } );
    }

    /**
    * The actual entry-point method, invoked once the uncaught exception
    * handler got properly registered.
    */
    protected abstract void doOnModuleLoad();
    }

  • Jeff Richley says:
    July 17, 2012 at 9:17 am

    That is some great stuff! It is quite tricky to figure out that the default handler won’t be called in the onModuleLoad(). I love the trick about “deferring” the module loading. That is a neat trick! I’m going to have to make a post just about that.

Leave a Comment