Take care when logging Exceptions!

Today I was facing some weird nullpointer exceptions (NPEs) in my Android App (Beta phase, luckily). Usually I catch exceptions like

try{ .. }catch(SomeException e){ 
   logger.info("A SomeException occured, but i got it.", e) 

Well in this part of the code I broke with my habit and wrote:

try{ .. }catch(SomeException e){ 
   logger.info("A SomeException occured, but i got it: "+e.getMessage(), e) 

And guess what. I experienced the expected exception, caught it (great) – and got a NPE somewhere in the Loggin framework. WTF?
After having a quick look at the Throwable API, I realized that getMessage() can indeed return null. And String+null produces null. So I nulled my logging message and passed this null reference right into the logging call – which produced the NPE in there. This was very annoying as I successfully caught the first exception – just to produce a susbsequent error during handling the first one.

Well, I immediately grepped my whole project for any strings like .getMessage() and checked for any other NPE traps.
Lesson learned today: carefully check the Api docs and be even more paranoid for NPEs.
Yet one question remains unanswered: Why on earth would one like to return null references in exceptions instead of empty strings?!

An introduction to the Logging framework (a.k.a. System.out.println is evil)


One of the first lines a programmer will write in a new language is surely “Hello World”. In Java you can write to the console or to the error stream quite easy with a simple System.out.println("Hello World") or System.err.println("Hello Error"). Great! When the code grows, bugs creep into the code and make live a bit harder. At this point programmers should definately start a deep and loving relationship with the debugger that is delivered with the IDE instead of using System.out/err.println() as debug method. Nevertheless – there are at cases, where a Debugger cannot (or hardly) be applied:

  1. The code runs in the IDE but not if startet directly. – What the hell’s going wrong?
  2. Handling of exceptions. An exception indicates a state that should not have happened and therefore it might be considered to be logged.
  3. The code is deployed to someone else and you cannot attach the debugger to his/her machine.

At either point, beginners tend to use System.out/err.println() to trace the execution path. While this might be okay if the onlyone that is using the code is the programmer alone, this can be very annoying if you are working in a team: If you forget to remove the debug messages, you’re polluting someone elses console output. Even worse: if the code is deployed to a client which reports an error, you cannot raise/lower debug levels or just enable/disable debugging. Do you really want to send a “debug version”? (No you wouldn’t.)

Continue reading An introduction to the Logging framework (a.k.a. System.out.println is evil)