exceptions in static initializers

Discussion in 'Java' started by HK, May 30, 2005.

  1. HK

    HK Guest

    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.
     
    HK, May 30, 2005
    #1
    1. Advertising

  2. 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
     
    Andrea Desole, May 30, 2005
    #2
    1. Advertising

  3. HK

    Wibble Guest

    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.
     
    Wibble, May 30, 2005
    #3
  4. HK

    Guest

    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
    }
     
    , May 31, 2005
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. j l
    Replies:
    5
    Views:
    408
    A. Bolmarcich
    Feb 23, 2004
  2. James Robert Leek

    JNI Invocation: static UN-initializers?

    James Robert Leek, Aug 31, 2004, in forum: Java
    Replies:
    2
    Views:
    514
    James Robert Leek
    Aug 31, 2004
  3. HK
    Replies:
    7
    Views:
    432
    Wibble
    May 30, 2005
  4. Ric Has
    Replies:
    3
    Views:
    3,260
    Ric Has
    Oct 13, 2004
  5. Christopher Benson-Manica

    References to static fields in enum initializers

    Christopher Benson-Manica, Jul 5, 2007, in forum: Java
    Replies:
    1
    Views:
    348
    Christopher Benson-Manica
    Jul 5, 2007
Loading...

Share This Page