commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [logging] improved exception diagnostics [WAS Re: [logging] work needed for 1.0.4]
Date Mon, 01 Mar 2004 02:44:23 GMT
Quoting robert burrell donkin <>:

> (new thread to discuss these issues.)
> On 28 Feb 2004, at 19:37, Dennis Lundberg wrote:
> > #25156 [logging] Enhance error message for 
> > "org.apache.commons.logging.impl.Log4JLogger does not implement Log"
> > - This seems to me to be similar to #26598
> >
> > #26598 [logging] org.apache.commons.logging.impl.LogFactoryImpl does 
> > not provide enough information on an InvocationTargetException in the 
> > newInstance() method.
> > - This is something that has to be decided on. It involves catching an 
> > extra Exception to provide a better error-message. Code that shows how 
> > to do it is available in the bugreport.
> these are about making it easier for people to work out what's gone 
> wrong when a LogConfigurationException is thrown. at the moment, all 
> throwables are caught and rethrown as LogConfigurationException's. this 
> includes InvocationTargetException's. (see 
> i think it's important to understand that any change in this area would 
> probably result in a change in exception handling symantics. any code 
> that processed LogConfigurationException's by using getCause may be 
> effected by a change in this area.

In other code that deals with InvocationTargetExceptions, I've found myself
migrating more towards code that behaves as this enhancement request reports,
for precisely the reason being reported here (usability).  Therefore, I'm
inclined to say "yes" on this one.

> the requests for changes seem (to me) to be focussed mainly on improved 
> diagnostics (more meaningful stack traces and messages). we may be able 
> to retain the older symantics by changing LogConfigurationException so 
> that it extracts the target exception and uses that for stack traces 
> and to create the message but still sets the internal cause as it does 
> now.

The only visible semantic change will be to people that are currently unwrapping
InvocationTargetException instances themselves to get at the underlying cause. 
If LogConfigurationException never includes one, that code will never get
executed, so we're just saving the applications an extra unwrap step, in
addition to making exceptions more readable if we didn't do the unwrap

A couple of notes if we decide to implement this:

* As Dennis points out, we should be calling
  for pre-1.4 compatibility.

* It's still possible for an ITE to have a null
  cause, in which case we should pass the ITE into
  the constructor for LogConfigurationException
  (it's better than a null).


> comments, anyone?
> - robert
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message