One of the things that I have been doing now that I have not done before is using a logging utility to keep track of what is happening. We've been using Jakarta Commons Logging which is just a thin wrapper that doesn't bind you to any logging impl (like log4j).
From the examples that I had seen, I liked how it looked when you were logging exceptions, in that you could pass a message and the exception (javadoc). It would look like this: log.error(e.getMessage(), e);
The weird thing is that the error message takes "Object" for a message, and not String. Okay, I guess that's more flexible, but that's not the point. The problem with this is that getMessage can return null and the logging impl was not checking if the objects that I was passing in were null. So, I had code somewhere that I wrote that created a NullPointerException. I passed this in with the message as the first pram, and then the logging itself was generating another NullPointerException! Now, I would would have thought that it's one of those places (in logging) were you would want to protect the app as much as possible. I guess that it's always a call, do you want to "fail silently" or "fail fast, fail hard". I just wish someone had chosen the former.
I'm not sure under which circumstances it would happen that e.getMessage() is null, but in any case, couldn't you just check if it was null before passing it to the function in your catch statement. Maybe create wrapper class for your logger stuff is done automatically. Or all this doesn't matter if you are actually writing the logger, you could just perform this check yourself.
ReplyDeleteCheck the API that I linked to for the cases where it is null. ;-) (I had to actually fix the link... my bad)
ReplyDeleteYes, I *could* create a wrapper for the wrapper of the logging impl, but...
I just wanted to vent and remind people that Throwable.getMessage() can return null... It's the assumptions that fail that make programs crash.