[izpack-devel] IzPack exception generation/handling

[Julien Ponge]

(I've been willing to answer to this one for some time now, sorry)

> 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).

Yes, this is a bad way to handle exceptions.

> 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"); } ?

It would be dawn better!

> 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.

I fully agree with this. I would add that sometimes it can be worth
wrapping non-fatal exceptions in RuntimeException, but not everybody
agrees on this pattern.

If you have some time to devote in for this cleanup work, then you
have my green flag :-)

Cheers