Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
} catch (ProcessingException e) {
+ // Log the original exception
+ getLogger().error("Failed to process error handler for exception", e);
throw e;
I think we had an agreement against mile-long log files. Why log exception here if it will be logged later on (by the caller)?
Oops, sorry. I wanted to log "ex", the original exception, that got lost if there was an exception in the error handler.
} catch (Exception e) {
throw new ProcessingException("Failed to handle exception <" + ex + ">", e);
}
(note: here it is logged at all)
Yep. But here again we loose the original exception's stacktrace.
BTW, talking about mile-long logs: we hava a number of exception classes that log themselves and their chainged exception if present. And there are also some exceptions (like SAXException) that can be chained but don't log their cause. Add to this JDK 1.4's printStackTrace that also prints the stacktrace of nested exceptions.
The result is that we currently can have some exceptions being dumped multiple times because they are dumped by their parent and also by the JDK 1.4, and other exceptions whose cause is not printed in the logs at all because they're shielded by their wrapping exception.
So, what about:
- remove the printStackTrace() methods that also print the stacktrace of nested exceptions
- add a new %{rootThrowable} for the CocoonLogFormatter that prints the root exception, as given by NotifyingBuilder.getRootCause.
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
