Hello Andy,
Thank you for taking the time to express your concerns. I appreciate it. While I agree with most of your comments, it think it is important to put them in relation with the facts.
1) The NPE problem cannot be triggered from configuration files but only by java code actively trying to set up a custom RepositorySelector. At this time, very few people do that.
2) Item 1.2 in the FAQ, is one of the guiding principles behind log4j. You correctly point out that not catching the NPE contravenes this principle.
My argument is two fold.
1) This particular NPE problem concerns only few select developers all of which are expected to be of high caliber or at least curious enough to spend a few cycles on the problem. (Admittedly, they can make mistakes too.)
2) The particular defensive solution proposed was of the "ignore the developer, log4j knows best" kind. Hence, my -1.
Catching the NPE and providing the user with a useful pointer (pun unintended) is a solution worth exploring. However, currently we have other problems affecting many more users, hence my request to put the NPE aside for the time being. We can easily come back to it later.
At 02:00 AM 12/3/2004, Andy McBride wrote:
Please don't allow log4j to throw any unnecessary RuntimeException's be they NullPointers or IllegalStateExceptions.
According to the log4j FAQ question 1.2:
"log4j will not throw unexpected exceptions at run-time potentially causing your application to crash. If for any reason, log4j throws an uncaught exception, please send an email to the [EMAIL PROTECTED] mailing list. Uncaught exceptions are handled as serious bugs requiring immediate attention"
Simply documenting the problem will not help.
"... the RepositorySelector API is designed to be used by developers of Application Servers or 1st class passengers on the clue train..." - I would hope that there are more than 5 of these currently on planet earth and that some of them are capable of mistakes too! Far too many people only get round to reading the docs after the problem has occurred.
If I supply log4j with an invalid config file I do not expect it to crash the appserver, similarly if I programatically configure log4j RS incorrectly I also do not expect it to crash the appserver.
Putting my Miss Piggy hat on, I think I would always prefer log4j to ignore me and carry on with its existing basic default behaviour if I tried to instruct it to do something silly. A specific checked exception could be (self-f)logged pointing to the exact problem with the config.
These are just my humble opinions, please let the debate on this run a bit longer.
Regards
Andy
-- Ceki G�lc�
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
