Quoting robert burrell donkin <[EMAIL PROTECTED]>:
<snip>
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
ourselves.
A couple of notes if we decide to implement this:
* As Dennis points out, we should be calling InvocationTargetException.getTargetException() 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).
i can definitely live with the above solution.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
