--- [EMAIL PROTECTED] wrote: > > 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.
Deprecation means there's an alternate solution and future removal. Deprecating a class that will be used and not removed is confusing. David > > Eric Pabst > > > > |---------+---------------------------> > | | "Noel J. | > | | Bergman" | > | | <[EMAIL PROTECTED]| > | | m> | > | | | > | | 06/24/03 12:15 | > | | PM | > | | Please respond | > | | to "Jakarta | > | | Commons | > | | Developers List"| > | | | > |---------+---------------------------> > > >---------------------------------------------------------------------------------------------------------------| > | > | > | To: "Jakarta Commons Developers List" > <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> | > | cc: > | > | Subject: RE: Checked vs Runtime exceptions > | > > >---------------------------------------------------------------------------------------------------------------| > > > > > 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] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
