Is this your first time here? SwingWiki is a Java Swing Developer community site with an big archive of Swing-related usenet groups and mailing lists, but also tips, tricks and articles and book reviews written by your colleagues from around the world. If you came here through a search engine and did not find what you were looking for, make sure to check the wiki table of contents.

Use exception listeners

Standard Swing event delegation action model (ActionListeners, TableModelListeners and similar) usualy does not declare any exceptions thrown out of event processing methods. The reason for this, I think, is in the threaded model of execution (see Swing Threading), which makes it really hard to synchronously react to errors - processing of an event triggered by a single user action may span across multiple threads, and perhaps even be asynchronously delayed. Whatever the reason, you can not add new exceptions to the method signature when overriding it, so there is no way to throw a checked exception out of a event handler method. The same applies to most models (TableModel for example).

So, how to react to errors and thrown exceptions?

First of all, it is absolutely wrong to just discard exceptions. Silent errors, discarded in the background, are impossible to track down later. Throwing an unchecked exception from the method also is not a good solution, for the same reason that the interface does not declare checked exceptions. You have to deal with errors, and deal with them inside the event handler method.

The first impulse might be to display a JOptionPane with an error message, or notify the user visually about the error in some other way, but don’t do it either. Event handlers and data models are not visual components (and do not belong to the presentation/view layer - see MVC), so it would be wrong to mix the business and model code with presentation code. What you should do is use an exception listener.

Exception listener is similar to the event listener, but receives exceptions and not GUI events. Package java.beans contains an ExceptionListener interface - there is absolutely no rule that requires you to use it, but why reinvent the wheel? Add a setExceptionListener(ExceptionListener) method to your models and event handlers, and then call the listener.exceptionThrown() method when you catch an exception that you would normally throw out of an event handler. This way, something else will process the exception (so, it is just like throwing it out of the method).

Using exception listeners makes your application more flexible. You can later decide to log exceptions, display an error message on the screen, abort the execution or whatever. And, you will have an option of using a consistent, application-wide error reporting mechanism (JOptionPane modal error dialog over the application frame, for example).

Similar goal can be achieved by creating an exceptionThrown method in your singleton Application class (see Use Singleton Application), and call that method from the handler. This approach does not require you to install an exception listener into event handers and models, but reduces flexibility - using ExceptionListeners enables your classes to be reused in other applications, and also gives you an option to define several Exception handlers.


Comments? Corrections? Contact us or Login to edit pages directly (registration is free and takes less than displaying a JLabel)
  best/use_exception_listeners.txt · Last modified: 2005/03/13 11:31 by (gojko)
Recent changes | RSS changes | Table of contents | News Archive | Terms And Conditions | Register | The Quest For Software++| Ruby Resources

Sedo - Buy and Sell Domain Names and Websites project info: Statistics for project etracker� web controlling instead of log file analysis