When a static initialization block throws an exception, the JVM wraps it in an ExceptionInInitializerError and marks the class as having failed initialization, meaning the class can never be successfully initialized in that JVM for the rest of its run.
Key Points: • The original exception is wrapped as the cause of a java.lang.ExceptionInInitializerError, which itself is an unchecked Error. • Once static initialization fails, the class is left in an erroneous state permanently for that JVM instance — it will never be retried. • Any subsequent attempt to use the class, such as creating an instance or accessing a static member, throws NoClassDefFoundError, referencing the earlier initialization failure. • This behavior enforces a guarantee: code can rely on the fact that if a class is usable at all, its static initialization definitely completed successfully. • Because the failure is permanent for the JVM's lifetime, static initializers should avoid risky operations, like I/O that can fail, unless the failure is genuinely meant to be fatal for the application.
Example: A class with a static block that parses a configuration value and throws a NumberFormatException on bad input will fail to initialize; every later reference to that class anywhere in the application then throws NoClassDefFoundError, even in code paths unrelated to the original config parsing.
Interview Tip: A concise interview answer is:
"An exception thrown in a static initializer gets wrapped in an ExceptionInInitializerError, and the class is permanently marked as failed to initialize for that JVM run. Any later attempt to use the class throws NoClassDefFoundError instead, which is why static initializers should avoid operations that can fail unless a hard startup failure is actually the intended behavior."