commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: DBCP/LANG
Date Sun, 11 Aug 2002 19:58:35 GMT
Avalon already has an ExceptionUtils class. A useful exception to string
method is currently in [util] as a holding measure. So I would think that
[lang] could easily have a ExceptionUtils added to its exception
subdirectory. Then there is no reason why it can't do what you suggest. (You
don't have any code to start from do you ;-)

NestedException will still be needed for those people writing _new_
exceptions that
- need less than JDK 1.4 compatability
- want getCause functionality without coding it themselves

Thus NestedException and ExceptionUtils become complementary.

Stephen

----- Original Message -----
From: <costinm@covalent.net>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Cc: <nicolaken@apache.org>
Sent: Sunday, August 11, 2002 8:38 PM
Subject: Re: DBCP/LANG


> On Sun, 11 Aug 2002, Stephen Colebourne wrote:
>
> > > I'm +1 for removing NestableException from lang, in favor of utulity
> > > methods.
> >
> > -1
> > We don't all use JDK 1.4. NestableException is a highly useful way of
> > handling exceptions. The fact that everyone tends to write their own
> > suggests that there should be a common implementation. I know that not
> > everyone favours exception wrapping, but it is a recognised technique
used
> > by many people in many places including the JDK. This will stay.
>
> I think you got it wrong.
>
> Everyone is designing exceptions based on their needs - and it is indeed
> a very common pattern to use a getCause() on the exception, and tools
> like the logger can use this pattern ( and introspection in pre-1.4,
> Throwable.getCause() in 1.4 ).
>
> That doesn't mean there is a need for a NestableException base class
> that projects should use ( i.e. TomcatException extends
> NestableException).
>
> There is need for common code to parse the stack trace and helper to
> manipluate the nested exceptions - but [lang] is completely useless for
> that, if a project doesn't extend NestableException, it won't get any
> help.
>
> In other words - I don't think tomcat ( for example ) will change the
> exceptions to extend NestableException, especially when the same benefits
> can be achieved using a tool that can manipulate arbitrary exception (
> including ServletException, etc ).
>
> Of course, that doesn't mean I want it removed from lang - just that it
> raises red flags for me, as I said I don't like very much utils
> that require users to change their APIs ( and the exception hierarchy
> is part of the API).
>
> Since commons allows duplication - I'll just wait for a general-purpose
> exception helper that will do the same thing on arbitrary exceptions.
>
> Costin
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


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


Mime
View raw message