How not to handle exceptions from static code block in Java

Saw a “post at taragana.com”:http://blog.taragana.com/index.php/archive/how-to-handle-exceptions-from-static-code-block-in-java on “How To Handle Exceptions From Static Code Block in Java”. It came down to advocating logging it and rethrowing a runtime exception which would “normally ends the program execution”. Sorry, but I couldn’t let this piece of extremely bad advice slide… You should _never_ throw any exception out of … Continue reading “How not to handle exceptions from static code block in Java”

Saw a “post at taragana.com”:http://blog.taragana.com/index.php/archive/how-to-handle-exceptions-from-static-code-block-in-java on “How To Handle Exceptions From Static Code Block in Java”. It came down to advocating logging it and rethrowing a runtime exception which would “normally ends the program execution”. Sorry, but I couldn’t let this piece of extremely bad advice slide…


You should _never_ throw any exception out of a static code block (aka static initializer). Not even a runtime exception.

Why? Static initializers are called when the class definition is loaded (e.g. by invoking Class.forName(“foo.bar.Xyz”)). Any exception thrown by the static initializer will be passed through to the invoker, which in many cases will log it and move on – not abort the JVM.

However – the class is still loaded. Future attempts to refer to it result in a very-hard-to-diagnose ClassDefNotFoundException – these can easily swamp your logs so that the original exception can not be located. By throwing the exception out, you’ve actually made it a _lot_ harder to pin down the cause.

It’s much better to not throw the exception then, but check to see if the class initialized properly when needed (e.g., inside the constructor, or inside static methods) and throw a meaningful exception (runtime or otherwise) at that point. Even better still, if you can swing it, would be to defer the initialization to that point. This helps avoid side effects caused by the class definition being used in a different way (e.g. being examined via reflection inside of a debugger).

Author: Robert Watkins

My name is Robert Watkins. I am a software developer and have been for over 20 years now. I currently work for people, but my opinions here are in no way endorsed by them (which is cool; their opinions aren’t endorsed by me either). My main professional interests are in Java development, using Agile methods, with a historical focus on building web based applications. I’m also a Mac-fan and love my iPhone, which I’m currently learning how to code for. I live and work in Brisbane, Australia, but I grew up in the Northern Territory, and still find Brisbane too cold (after 22 years here). I’m married, with two children and one cat. My politics are socialist in tendency, my religious affiliation is atheist (aka “none of the above”), my attitude is condescending and my moral standing is lying down.

2 thoughts on “How not to handle exceptions from static code block in Java”

  1. Wrong, both of you.

    It’s perfectly fine to throw a RuntimeException in a static initializer, because the JVM will catch it and rethrow a java.lang.ExceptionInInitializerError, which is an Error and hence should not be caught.

    Reply

  2. Henry, you are wrong… not about the ExceptionInInitialzerError, which is merely the way the exception gets passed back, but because of the effect the exception has on the class definition. The NoClassDefFoundError which occurs on subsequent access to the class will drown that original exception.

    And you _can_ catch Errors. If you weren’t allowed to catch them, they wouldn’t descend from Throwable. There are many situations where you do want to deal with Errors – I’m sure if you stop to think of them, you will.

    Reply

Leave a comment