commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: DBCP/LANG
Date Sun, 11 Aug 2002 20:44:24 GMT
On Sun, 11 Aug 2002, Stephen Colebourne wrote:

> 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 ;-)

I don't. I sent a patch to log4j few days ago that uses introspection
to find the root cause, extracted from tomcat3 Logger ( in util.qlog).
And you can find in jasper code that does a lot of parsing ( to locate
the line number and do the mapping ). 
You can cut&paste if you want, but it's just code we use, not a
real codebase for an ExceptionUtils.


> 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

Exceptions are part of the API. Commons should't mess
with the API of the application that uses them. I think that's out
of scope for commons, but may very well fit in other projects.


Costin



> 
> 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>
> 
> 


--
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