[izpack-devel] IzPack exception generation/handling

[Hans Aikema]

Browsing through IzPack's code I see a lot of 'throws Exception' statements.

In general I tend to consider this bad coding habit since catching those 
in the caller would mean that caller also catches other Exceptions it 
never intended to catch (most significant being the RuntimeExceptions).

Wouldn't it be better to introduce a few IzPack specific Exceptions 
instead of coding 'throws Exception' combined with 'if 
(somethinggoeswrong) { throw new Exception("tell what's wrong"); } ?

I would be glad to hear your opinion on what would be the best 
strategies for exception-generation/handling and would like to invest 
some of my time working to clean up current IzPack classes to use those 
strategies.

My first thoughts:
-If IzPack-code decides there should be an exception we should 
preferably use either an appropriate Java 1.4 provided exception-class
-When an appropriate class is not provided by Java 1.4 we should define 
our own exception class and throw an instance of that class
-When IzPack code calls methods that (might) throw exceptions we don't 
want to catch we should explicitly declare all thrown exceptions rather 
than declaring only a shared parent-class for some of the specific 
exceptions.
-When we don't want to burden our caller with a long list of exceptions 
we catch those exceptions and throw an IzPack defined exception instead 
which wraps to original exception rather than falling back to using a 
shared superclass (which might result in additional exceptions being 
forwarded to the caller unintended since javac never notifies us of the 
uncaught exception).
-We never (well... almost never) catch a common superclass of 
encountered exceptions, but rather specify each seperate exception 
(optionally using a common private method to write handling code for 
similar errors only once in a class). The only exception being catching 
any exception in an external class/package beyond our control, where we 
might want to catch java.lang.Throwable, then figure out what to do with 
the error and handle the Throwable accordingly.

regards,
Hans Aikema