Bug 44038 - log4j is susceptible to exceptions thrown by Exception classes
Summary: log4j is susceptible to exceptions thrown by Exception classes
Alias: None
Product: Log4j - Now in Jira
Classification: Unclassified
Component: Appender (show other bugs)
Version: 1.2
Hardware: All other
: P2 critical
Target Milestone: ---
Assignee: log4j-dev
Depends on:
Reported: 2007-12-07 10:29 UTC by David Johnson
Modified: 2009-01-28 05:57 UTC (History)
2 users (show)

Example to simply reproduce bug. (1.59 KB, text/java)
2009-01-28 01:43 UTC, Florin Vancea

Note You need to log in before you can comment on or make changes to this bug.
Description David Johnson 2007-12-07 10:29:17 UTC
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.
Comment 1 Dan Armbrust 2007-12-19 14:31:18 UTC
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.  
Comment 2 Thorbjørn Ravn Andersen 2008-06-30 13:09:56 UTC
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?
Comment 3 Florin Vancea 2009-01-28 01:43:08 UTC
Created attachment 23185 [details]
Example to simply reproduce bug.
Comment 4 Florin Vancea 2009-01-28 01:51:27 UTC
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.
Comment 5 Florin Vancea 2009-01-28 02:11:26 UTC
Adding myself to cc.
Comment 6 Curt Arnold 2009-01-28 05:57:06 UTC
Committed fix in rev738488