David,
>>
http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWe
reAMistake.html
>> 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
checked.
> 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 layers
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
