Griffon: Dealing with uncaught exceptions

How many times have you encountered a rogue exception that bubbles up to the top of the call stack, causing an application to crash and burn? At least a few times, right? Fortunately the JDK provides a handy mechanism for dealing with such exceptions: Thread.UncaughtExceptionHandler. OK, so registering an implementation of such type should be enough to get the application back on track, however you're out of luck if an exception happens inside the EventDispatchThread. You'll need to register the implementation in a different way. More over, unless your design includes some form of multiplexing the handling of the exception, then only one component will be able to handle said exception. Allow me to introduce a different way to handle uncaught exceptions regardless of the place they are thrown.

The Griffon SDK includes a class named GriffonExceptionHandler whose main responsibility is to catch any exceptions that your code did not catch, including those thrown inside the EventDispatchThread. It does so by implementing the Thread.UncaughtExceptionHandler interface and registering itself in the following manner:
public static void registerExceptionHandler() { Thread.setDefaultUncaughtExceptionHandler(new GriffonExceptionHandler()); System.setProperty("sun.awt.exception.handler", GriffonExceptionHandler.class.getName()); }This takes care of the first issue but it does not solve the second one. Another responsibility of this class is to propagate events through the Griffon event bus (Hamlet recently posted a screencast on this topic, go check it out!). Now any component that registers itself with the application as an event listener will get a chance to react to these type of exceptions. Let's see a quick example.

Assuming that you have a Griffon application with the following View and Controller classes

BombView.groovy
package bomb actions { action(id: 'action1', name: "There's a hidden bug in this app...", smallIcon: nuvolaIcon('bug', category: 'apps'), closure: controller.buggyAction) } application(title: 'Exception Handler Test', pack: true, locationByPlatform:true, iconImage: imageIcon('/griffon-icon-48x48.png').image, iconImages: [imageIcon('/griffon-icon-48x48.png').image, imageIcon('/griffon-icon-32x32.png').image, imageIcon('/griffon-icon-16x16.png').image]) { button(action1) } BombController.groovy
package bomb class BombController { def buggyAction = { throw new BombException() } }Clicking on the button triggers an exception but the Controller nor the View have code that can handle it. If GriffonExceptionHandler were not automatically registered at boot time then the application would end abruptly as soon after you click that button. Praise goodness that's not the case! But how do we add code that handles the exception? Of course you can add a try/catch block to the controller action but that would defeat the purpose of showing the event bus in action. Every Controller (and Service instance for that matter) in Griffon are registered as application event listeners automatically. We could add an even listener to the Controller, however that would be akin to adding a try/catch in the action, i.e, the component that throws the exception is also the one that handles it. We'll choose a different route and register a global event handler for this case.

Global event handlers are the same as any other event handlers, the only difference is that they are defined in a special script (griffon-app/conf/Events.groovy) or class (src/main/Events.java). Here's a quick way to deal with the event
Assuming that you have a Griffon application with the following View and Controller classes

griffon-app/conf/Events.groovy
onUncaughtBombException = { e -> println "Oops, got an unexpected exception $e" }This should result in a similar output on your console once you click on the button


If you look closer to the output on your console you should also see something akin to this


That's right, GriffonExceptionHandler will also log the exception for you, it will even filter the stack trace so that you don't see any groovy internals nor java reflection bits. There's more information about this feature at the Griffon Guide, section 5.5.10. With a few more lines of code you can build an event handler that presents a dialog to the user, like this one


I'll show how to get it done on a future post but if you're feeling impatient then jump to Github and clone the sample bomb application.

Keep on Groovying!