commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <>
Subject Re: [VFS] Softening the exceptions...
Date Mon, 25 Oct 2010 17:47:12 GMT
On Mon, Oct 25, 2010 at 1:17 PM, Steven Siebert <> wrote:
> I agree with Mark's point about unfamiliar developers benefiting from
> checked exceptions.  Unlike James, I like checked exceptions =), and I have
> established "elegant" recoveries from various resource exceptions (IO, for
> example) under many use cases (at least in the enterprise arena).

Sure, a newbie might enjoy the warm fuzziness they feel when they know
what type of exception they have to catch when they call a certain
method.  However, that newbie, when they get familiar with said API,
will start writing work-arounds so they don't have to have all those
pesky catch blocks in their code.  They will quickly realize that
typically there isn't a darn thing they can really do when this type
of exception occurs.  Mostly, the exceptions are best handled up the
call stack by some "global" means.  So, in order to do that, you
either have to allow all your methods to throw the exception or
"tunnel" the exception up the call stack by wrapping it in a runtime
exception and throwing that.  Even if there is a retry/recovery
option, you'd use some utility method to do that, so you'd only have
the try/catch in one place as opposed to everywhere.

> What's everyones opinion on more "descriptive" Exception typing to allow me
> to handle specific failures easier (without additional testing)?  I can
> probably go through my code and find some examples if necessary...

I like the idea of a more descriptive hierarchy of exceptions.
Exception classes are cheap, really.  Hibernate does this (optimistic
locking exception comes to mind) and it seems to work pretty well.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message