exceptions in static initializers

[HK]

Ever so often I find side remarks in
postings that exceptions in static
initializers are a pain/bad/hard to
track/etc. I wonder why this seems
to be so common?

Let me elaborate: There are two
completely different cases of
exceptions:

a) The exception is triggered by a
bug, i.e. the situation is completely
under the control of the programmer and
he messed it up: The line

"bla".matches("(");

will result in a PatternSyntaxException
and the programmer should have known better.

b) The exception is a true exception, i.e.
the programmer has no chance at all to
prevent it to happen:

"bla".matches(getRegexpFromUser())

I would most probably not write a static
initializer where (b) might happen, but
case (a) exceptions are quite common.

I simply write then

static {
try {
// do stuff which should not
// throw except for a bug
} catch( SomeException e ) {
throw new Error("bug", e);
}
}

Now if I screwed up, I get the "bug"
exception with a nice stack trace.
What is wrong about it?

The only thing I could think of is
that unit testing is a bit strange
for those initializers.

Harald.

 

[Andrea Desole]

Ever so often I find side remarks in
postings that exceptions in static
initializers are a pain/bad/hard to
track/etc. I wonder why this seems
to be so common?

Let me elaborate: There are two
completely different cases of
exceptions:

a) The exception is triggered by a
bug, i.e. the situation is completely
under the control of the programmer and
he messed it up: The line

"bla".matches("(");

will result in a PatternSyntaxException
and the programmer should have known better.

b) The exception is a true exception, i.e.
the programmer has no chance at all to
prevent it to happen:

"bla".matches(getRegexpFromUser())

I would most probably not write a static
initializer where (b) might happen, but
case (a) exceptions are quite common.

I simply write then

static {
try {
// do stuff which should not
// throw except for a bug
} catch( SomeException e ) {
throw new Error("bug", e);
}
}

Now if I screwed up, I get the "bug"
exception with a nice stack trace.
What is wrong about it?

two things are wrong:

1) if the code in the static initializer is a bit more complicated you
might go from a to b without noticing it

2) if there is a bug you didn't find the user will get the stack trace,
and not you. This is not very user friendly. Personally, I prefer a nice
handler that tells the user something wrong happened, and a log file.
You can never be 100% sure that your code is bug free

 

[Wibble]

two things are wrong:

1) if the code in the static initializer is a bit more complicated you
might go from a to b without noticing it

2) if there is a bug you didn't find the user will get the stack trace,
and not you. This is not very user friendly. Personally, I prefer a nice
handler that tells the user something wrong happened, and a log file.
You can never be 100% sure that your code is bug free

Static initializers sometimes eat the exception. Print the stack trace
before you rethrow it.

 

[iksrazal]

Keep in mind errors in static initializers are runtime exceptions. Yes,
you should log liberally. Read up on ExceptionInInitializerError. FWIW,
I do:

/** singleton's private instance */
private static ThreadedSocketManager _instance;

//Instatiate singleton with a static initializer
static
{
try
{
_instance = new ThreadedSocketManager();
}
catch (Exception e)
{
Fwlog.error(this, Fwlog.DB, e);
throw new ExceptionInInitializerError(e);
}
}

private ThreadedSocketManager()
throws SocketConnectionException
{
// do stuff
}