Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > exceptions in static initializers

Reply
Thread Tools

exceptions in static initializers

 
 
HK
Guest
Posts: n/a
 
      05-30-2005
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.

 
Reply With Quote
 
 
 
 
Andrea Desole
Guest
Posts: n/a
 
      05-30-2005


HK wrote:
> 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
 
Reply With Quote
 
 
 
 
Wibble
Guest
Posts: n/a
 
      05-30-2005
Andrea Desole wrote:
>
>
> HK wrote:
>
>> 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


Static initializers sometimes eat the exception. Print the stack trace
before you rethrow it.
 
Reply With Quote
 
iksrazal@terra.com.br
Guest
Posts: n/a
 
      05-31-2005
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
}

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
References to static fields in enum initializers Christopher Benson-Manica Java 1 07-05-2007 06:41 PM
static initializers vs. cached values HK Java 7 05-30-2005 05:28 PM
odd problem with static initializers Ric Has C++ 3 10-13-2004 06:12 PM
JNI Invocation: static UN-initializers? James Robert Leek Java 2 08-31-2004 09:13 PM
problem with static initializers j l Java 5 02-23-2004 09:58 PM



Advertisments