I am just now exploring both Vaadin 6 and 7. In implementing a button click listener, I find this super annoying:
Button btnNew = new Button("New", new Button.ClickListener() {
public void buttonClick(ClickEvent event) {
try {
doThingThatThrowsException();
} catch (Exception exc) {
handleException(exc);
}
}
});
I’ve written my own framework and also used Zk. Both frameworks declare all event listeners to throw Exception. The frameworks then capture all uncaught exceptions and present the appropriate feedback to the user as well as clean up database resources and log the error.
I can imagine I’ll get tired of writing listeners that constantly have to try/catch.
If your application logic throws checked exceptions caused by something outside the coder’s control (i.e. database connection failed or some file not found), then your application logic is also the only code that knows how to cope with those exceptions (e.g. choosing between retrying, trying something similar instead or just giving up and showing a message to the user) and it’s thus your application logic’s responsibility to react to such exceptions. This is why the framework forces you to take care of your own exceptions by not defining listeners to throw Exception.
If the exceptions on the other hand are unchecked (i.e. caused by missing null checks or other direct bugs in some code), then the framework might as well take care of displaying some generic error message, because there is probably nothing that can be done to the problem other than fixing the actual bug. As unchecked exceptions doesn’t require any explicit throws definition, you don’t need to do anything in your application logic for these.
It doesn’t matter if I handle checked exceptions at the level of the event handler or at the top level of the application somewhere. I can choose to handle it at the event handler level if I want to handle the error in a manner specific to the task at hand, or I can let any exceptions bubble up to the top. Most of the time I want a standard handling of exceptions “oops, something bad has happened and administrators have been notified”, plus some logging. I’ll handle a number of common exceptions slightly different, like OptimisticLockException.
Forcing me to handle exceptions in every event just leads to excessive boiler plate code. Please give us the options to work in whatever style we want.
I can see the pros and cons both arguments here, and I believe that there is no solution that Vaadin could implement that would appease both “camps” - one approach is diametrically opposed to the other.
However, isn’t it is fairly trivial for us as users to write abstract listener class that handle exceptions in the way that we like ? This gives you the option to work the style that you want to, without having to do boiler-plate in every handler.
I would agree, and that’s likely the approach I’d have to take. I just figured I’d take the opportunity to request the API change. Having the listeners declare “throws Exception” does not prevent coders from try/catching everything. True, it would allow coders to forget to catch since no compile errors would be generated. I am considering moving to Vaadin from Zk which throws Exception from all event listeners. Zk is a pretty successful framework that does quite a bit to avoid imposing a certain coding style.
There are quite a few event listeners and it’s a bit of a chore to have to wrap them all.
Sorry for ressurecting the post, but my doubt is pretty much related to this subject. I have a button and its click listener code may throw an application exception. In other points of application code, this exception is thrown all the way back to my custom window class, where it’s centrally handled. I’d like to do something similar here: throw this exception in the clickListener code, so I could catch it in my custom terminal error handler in the window class. As the click listener class does not throw any exception, I’m unable to throw the exception there and I think I’ll be obliged to handle the exception locally. As I don’t want to handle the exception at the button click listener level, I think I’ll forward it to my custom window class. Something like this:
I don’t know if that’s the usual way, but it’s pretty close to what I decided to do. In your case you have to pass around a reference to the window, I created a static handler on my Application class to handle it.