commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Checked vs Runtime exceptions
Date Tue, 24 Jun 2003 18:56:24 GMT

I agree.  I think that certain precautions could be taken:

The exception should have quite a disclaimer in the JavaDoc that it is NOT
recommended, and is only a standard work-around for tunneling through a
layer that does not support throwing checked exceptions, and is not in the
developer's control.  The developer should contact the authors of that
layer to submit it as a bug that it does not support checked exceptions,
and whoever implemented that layer should at the earliest opportunity allow
for them.  I wonder if this merits making the exception wrapper be
deprecated...   Using it should be avoided, but it would not be removed in
later versions of Commons.

Eric Pabst

|         |           "Noel J.        |
|         |           Bergman"        |
|         |           <|
|         |           m>              |
|         |                           |
|         |           06/24/03 12:15  |
|         |           PM              |
|         |           Please respond  |
|         |           to "Jakarta     |
|         |           Commons         |
|         |           Developers List"|
|         |                           |
  |        To:      "Jakarta Commons Developers List" <>,
<>      |
  |        cc:                                                                           
  |        Subject: RE: Checked vs Runtime exceptions                                    




>> Although I don't entirely agree with the analysis, I do agree that the
>> proposed technique can be useful.  Is this exception going to be added
>> somewhere to Jakarta-Commons for general use?  Where will it be packaged
>> for re-use?

> It would be sad to see the Commons start using RuntimeExceptions
> everywhere as it's a really poor design technique.

Personally, I dislike runtime exceptions.  They are the source of far too
many errors in far too much code.  Whenever possible, I always code checked
exceptions.  Unfortunately, not everyone does, and particularly prior to
nested exceptions, most code didn't know what to do about passing up
exceptions that weren't declared in the throws clause.

JavaMail's MessagingException, for example, is a checked exception that
nests any underlying exceptions that led to the MessagingException.  It is,
from that perspective, similar to the proposed solution, except that it is

> The reasoning for such an approach seems to be, "Pool throws unchecked
> exceptions and DBCP doesn't so we need a wrapper."  In that case, pool is
> in error, not DBCP.

I see his proposed technique as being useful in the case where we own
A and C, and need to get through layer B in the cleanest way, where layer B
doesn't expose a proper middleware understanding of exception handling.  I
would not want to see new middleware use his proposal as an "excuse" not to
provide for checked exceptions in the interface.

             --- Noel

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

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

View raw message