commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <grahamdavid1...@yahoo.com>
Subject RE: Checked vs Runtime exceptions
Date Tue, 24 Jun 2003 19:10:27 GMT
--- ericpabst@discoverfinancial.com 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"        |
> |         |           <noel@devtech.co|
> |         |           m>              |
> |         |                           |
> |         |           06/24/03 12:15  |
> |         |           PM              |
> |         |           Please respond  |
> |         |           to "Jakarta     |
> |         |           Commons         |
> |         |           Developers List"|
> |         |                           |
> |---------+--------------------------->
>  
>
>---------------------------------------------------------------------------------------------------------------|
>   |                                                                     
>                                          |
>   |        To:      "Jakarta Commons Developers List"
> <commons-dev@jakarta.apache.org>, <dgraham@apache.org>      |
>   |        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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message