There is a bug in the Spring 2.5 MailSendException class where it throws an exception on calls to getMessage and printStackTrace (see SPR-4138 in Spring's bug DB). This spring bug exposed what I consider a problem with log4j. Partial stack trace: Caused by: java.lang.NullPointerException at org.springframework.mail.MailSendException.printStackTrace(MailSendException.java:149) at org.apache.log4j.spi.ThrowableInformation.getThrowableStrRep(ThrowableInformation.java:59) I would expect log4j to use try/catch blocks around any calls it makes to Exception classes so that a consumer of the logging library can be confident that a call to a log(...) method will never throw an exception, even if a buggy exception reference is passed in. I'd rather get no message or stack trace in the output than have log4j pass the exception to my application. If this isn't addressed in log4j then I'll have to create a wrapper that around it that does trap any exceptions.
Yes, this seems like a really bad idea. I ran into this too. The telnet appender has issues that can cause a null pointer (bug 44109) and those blow right back out into calling code too. A call to "log" shouldn't ever throw an exception back - it should trap it and report is somewhere, perhaps to the loggers that are working, or at a minimum to the console.
This sound like a good idea. Just to be certain that the bug report is understood correctly, can you create a small example which shows the behaviour?
Created attachment 23185 [details] Example to simply reproduce bug.
I just bumped into the very same bug and since there was no recent activity I created an example myself. It proves the bug against 1.2.15. You will find the details in the attached file. I did not offer a patch because IMHO it's just a matter of try/catch in ThrowableInformation.getThrowableStrRep() and someone who knows log4j better might also know what smart thing may be appropriate after catching :) P.S. My real case was logging AxisFault through AsyncAppender. Somehow between logger.error(...) and effective buffer flush to disk the exception passed became invalid and caused the async appender to fail, producing later a global failure for the entire application.
Adding myself to cc.
Committed fix in rev738488