How to design an exception architecture in a software?

Discussion in 'Java' started by gooperaus, Dec 30, 2003.

  1. gooperaus

    gooperaus Guest

    Hi all,

    I got a problem to design an exception architecture in a big software
    with java. Because there are so many errors, I have to set up a lot of
    exception classes, it is so tedious.

    Should I use the error ID instead of exception classes?

    thx
     
    gooperaus, Dec 30, 2003
    #1
    1. Advertising

  2. gooperaus

    Dave Glasser Guest

    (gooperaus) wrote on 29 Dec 2003 18:37:32 -0800
    in comp.lang.java.programmer:

    >Hi all,
    >
    >I got a problem to design an exception architecture in a big software
    >with java. Because there are so many errors, I have to set up a lot of
    >exception classes, it is so tedious.
    >
    >Should I use the error ID instead of exception classes?


    Yes, without a doubt.


    --
    Check out QueryForm, a free, open source, Java/Swing-based
    front end for relational databases.

    http://qform.sourceforge.net
     
    Dave Glasser, Dec 30, 2003
    #2
    1. Advertising

  3. Dave Glasser wrote:
    >>I got a problem to design an exception architecture in a big software
    >>with java. Because there are so many errors, I have to set up a lot of
    >>exception classes, it is so tedious.


    Still less tedious than the other way.

    >>Should I use the error ID instead of exception classes?

    >
    >
    > Yes, without a doubt.


    No, certainly NOT! The exception system was designed for a good reason.

    Wherever it makes sense to handle different exceptions differently within
    the application, use different exception classes so that you can make use
    of catch clauses at the appropriate scope. Where this is *not* the case,
    your exceptions are, from the point of view of the program, identical. The
    difference should still be documented for humans to do error analysis.
    Error IDs are one way of doing that, but a pretty bad way since they
    are cryptic and have to be looked up.
     
    Michael Borgwardt, Dec 30, 2003
    #3
  4. gooperaus

    Guest

    Michael Borgwardt <> wrote:

    >Wherever it makes sense to handle different exceptions differently within
    >the application, use different exception classes so that you can make use
    >of catch clauses at the appropriate scope. Where this is *not* the case,
    >your exceptions are, from the point of view of the program, identical.


    Bingo.

    I'll just add that if you find code catching one type of exception and not
    doing anything special other than rethrowing it as a different type or
    wrapped in a different type, your exception handling could be improved.

    Design your hierarchy so that only the code that is going to do some task
    when an exception occurs is the only one that cares about catching the
    exception. There are situations where this just won't work, but it's an
    ideal to strive toward.
     
    , Dec 30, 2003
    #4
  5. gooperaus

    Dave Glasser Guest

    Michael Borgwardt <> wrote on Tue, 30 Dec
    2003 09:54:20 +0100 in comp.lang.java.programmer:

    >Dave Glasser wrote:
    >>>I got a problem to design an exception architecture in a big software
    >>>with java. Because there are so many errors, I have to set up a lot of
    >>>exception classes, it is so tedious.

    >
    >Still less tedious than the other way.
    >
    >>>Should I use the error ID instead of exception classes?

    >>
    >>
    >> Yes, without a doubt.

    >
    >No, certainly NOT!


    For the record, I was being sarcastic. Based on the vague, ambiguous
    way the question was worded, I don't see how the OP could expect an
    intelligent, informed response.

    That type of response would depend on what the OP actually meant,
    which is anyone's guess. If he's talking about creating a new,
    separate exception class for every single place where "errors"
    (whatever that means) might occur, simply to identify the location of
    the errors in his log file, then I would in fact recommend that he use
    some sort of error numbering scheme instead.


    >The exception system was designed for a good reason.
    >
    >Wherever it makes sense to handle different exceptions differently within
    >the application, use different exception classes so that you can make use
    >of catch clauses at the appropriate scope.


    A counterexample would be SQLException. You might handle a duplicate
    key exception differently than you would a hosed DB connection
    exception. To know which on you were dealing with, however, you would
    have to call getErrorCode() on the SQLException.


    --
    Check out QueryForm, a free, open source, Java/Swing-based
    front end for relational databases.

    http://qform.sourceforge.net
     
    Dave Glasser, Dec 30, 2003
    #5
  6. Dave Glasser wrote:
    >>Wherever it makes sense to handle different exceptions differently within
    >>the application, use different exception classes so that you can make use
    >>of catch clauses at the appropriate scope.

    >
    >
    > A counterexample would be SQLException. You might handle a duplicate
    > key exception differently than you would a hosed DB connection
    > exception. To know which on you were dealing with, however, you would
    > have to call getErrorCode() on the SQLException.


    That's not really a counterexample to what I was saying. It is simply bad
    design on the part of the API designers, resulting from a combination of
    necessity and laziness.
     
    Michael Borgwardt, Dec 30, 2003
    #6
  7. (gooperaus) wrote in message news:<>...
    > Hi all,
    >
    > I got a problem to design an exception architecture in a big software
    > with java. Because there are so many errors, I have to set up a lot of
    > exception classes, it is so tedious.


    You may want to write a simple program (possibly in Perl or something
    similar) that will generate the exception class source for you, rather
    than having to write it all by hand.
     
    Karl von Laudermann, Dec 30, 2003
    #7
  8. gooperaus

    Dave Glasser Guest

    Michael Borgwardt <> wrote on Tue, 30 Dec
    2003 17:37:24 +0100 in comp.lang.java.programmer:

    >Dave Glasser wrote:
    >>>Wherever it makes sense to handle different exceptions differently within
    >>>the application, use different exception classes so that you can make use
    >>>of catch clauses at the appropriate scope.

    >>
    >>
    >> A counterexample would be SQLException. You might handle a duplicate
    >> key exception differently than you would a hosed DB connection
    >> exception. To know which on you were dealing with, however, you would
    >> have to call getErrorCode() on the SQLException.

    >
    >That's not really a counterexample to what I was saying. It is simply bad
    >design on the part of the API designers, resulting from a combination of
    >necessity and laziness.


    Would you prefer different Exception classes -- perhaps all subclasses
    of SQLException -- for each of the hundreds of possible things that
    can go wrong when making a JDBC API call? (Each of which currently has
    its own SQL error code.)


    --
    Check out QueryForm, a free, open source, Java/Swing-based
    front end for relational databases.

    http://qform.sourceforge.net
     
    Dave Glasser, Dec 31, 2003
    #8
  9. Dave Glasser wrote:

    > Michael Borgwardt <> wrote on Tue, 30 Dec
    > 2003 17:37:24 +0100 in comp.lang.java.programmer:
    >
    >>Dave Glasser wrote:
    >>>>Wherever it makes sense to handle different exceptions differently
    >>>>within the application, use different exception classes so that you can
    >>>>make use of catch clauses at the appropriate scope.
    >>>
    >>>
    >>> A counterexample would be SQLException. You might handle a duplicate
    >>> key exception differently than you would a hosed DB connection
    >>> exception. To know which on you were dealing with, however, you would
    >>> have to call getErrorCode() on the SQLException.

    >>
    >>That's not really a counterexample to what I was saying. It is simply bad
    >>design on the part of the API designers, resulting from a combination of
    >>necessity and laziness.

    >
    > Would you prefer different Exception classes -- perhaps all subclasses
    > of SQLException -- for each of the hundreds of possible things that
    > can go wrong when making a JDBC API call? (Each of which currently has
    > its own SQL error code.)


    Why not?
    This is how the spring framework handles all data access exceptions. That
    way you can catch only the exceptions you know you will be able to handle
    (in Spring, they are all runtime exceptions), instead of having to look at
    errorcodes all over the place. It even has the same generic execption
    structure for JDO, JDBC, Hibernate, ... which I find to be really usefull.

    See
    http://www.springframework.org/docs/api/org/springframework/dao/DataAccessException.html
    for the details.

    --
    Kind regards,
    Christophe Vanfleteren
     
    Christophe Vanfleteren, Dec 31, 2003
    #9
  10. Dave Glasser wrote:
    >>>exception. To know which on you were dealing with, however, you would
    >>>have to call getErrorCode() on the SQLException.

    >>
    >>That's not really a counterexample to what I was saying. It is simply bad
    >>design on the part of the API designers, resulting from a combination of
    >>necessity and laziness.

    >
    >
    > Would you prefer different Exception classes -- perhaps all subclasses
    > of SQLException -- for each of the hundreds of possible things that
    > can go wrong when making a JDBC API call? (Each of which currently has
    > its own SQL error code.)


    Nope, only different classes for those errors or groups of errors where it
    obviously makes sense to handle them specially in the code. A dozen
    at most should suffice and would be a HUGE improvement.
     
    Michael Borgwardt, Jan 2, 2004
    #10
    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. Muhammad Khan
    Replies:
    4
    Views:
    1,227
    Mike Treseler
    Jul 10, 2003
  2. John
    Replies:
    0
    Views:
    1,032
  3. John
    Replies:
    0
    Views:
    1,046
  4. Juan A. Gomez-Pulido
    Replies:
    0
    Views:
    787
    Juan A. Gomez-Pulido
    May 24, 2009
  5. Juan A. Gomez-Pulido
    Replies:
    0
    Views:
    1,568
    Juan A. Gomez-Pulido
    Aug 24, 2009
Loading...

Share This Page