Thread: Right way to code a static initializer with fatal error?

Here's a Small C... I can never remember the rest ... it's an example of something that caught me out just now on another project. I'm initialising a static member with some code that throws Exceptions. I was at first surprised that the compiler demanded a return statement after the System.exit(), but then again it's a bit much to expect the compiler to know which methods never, ever return. Maybe in Java 8 there'll be an 'exit int' statement? I should be careful what I wish for.

Anyways, here's a contrived example that demonstrates the issue, I'd be interested to know how other Java coders handle the failed static initialiser, and how I can avoid the bogus return statement javac demands.

package com.javaprogrammingforums.domyhomework;
 
public class MissingReturnValue
{
  private final static int THE_ANSWER = theAnswer();
  private static int theAnswer()
  {
    try
    { /* imagine an exception here is a show-stopping disaster */
      return Integer.parseInt("42");
    }
    catch (Exception e)
    {
      e.printStackTrace();
    }
    System.exit(1);
    /* bogus return statement would go here */
  }
  public static void main(String[] args)
  {
    System.out.println("The answer is " + THE_ANSWER);
  }
}

Javac's output:

compiling...
/home/sean/tmp/MissingReturnValue.java:17: missing return statement
}
^
1 error

Ah okay, I've just reaped the benefits of the SC... (still can't remember. Any chance of a link? Say for example to the right of Java Careers? It's an important idea I hadn't seen in Initials until I came to JPFs) and re-arranged my code so that I have a variable declared outside the try..catch block, assign it in the try clause and return that at the end of the method. The System.exit() goes inside the catch clause. It still seems slightly nasty, so I'll leave this as-is in the hope that someone else might have a superior technique.

Just for posterity / discussion, while I'm struggling to read a consensus while searching for views on this elsewhere, I noticed a Sun document I'd never seen before that Oracle says has "completed the EOL process", so I'm uploading it here:

100PercentPureJavaCookbook-4_1_1.pdf

7. Pitfall: Misuse of System.exit
Explanation: The System.exit method forces termination of all threads in
the Java virtual machine. This is drastic. It might, for example, destroy all
windows created by the interpreter without giving the user a chance to record
or even read their contents.
Solution: Programs should usually terminate by stopping all non-daemon
threads; in the simplest case of a command-line program, this is as easy as
returning from the main method. System.exit should be reserved for a
catastrophic error exit, or for cases when a program is intended for use as a
utility in a command script that may depend on the program’s exit code.

So maybe I should think of a pattern that allowed me to detect failed static initialisation and exit gracefully? I can't think immediately what that would be...

rearrange the order of returns

That is what I've done at the moment: declare a reference that will hold the return value, set it to null, try to instantiate the object and assign it to the reference if it works, return the variable at the end.

This does look like the least bad option.

create a Singleton class

Maybe what's causing me the problem today is trying to keep some expanding utility code all in a single class, which means my static code has access to all the static data members and constructors. If I split this code up, then you're right and the problem doesn't exist to the same degree.