How to design an exception architecture in a software?

[gooperaus]

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

 

[Dave Glasser]

(e-mail address removed) (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.

 

[Michael Borgwardt]

Still less tedious than the other way.

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.

 

[brougham5]

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.

 

[Dave Glasser]

Still less tedious than the other way.


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.

 

[Michael Borgwardt]

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.

 

[Karl von Laudermann]

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.

 

[Dave Glasser]

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.)

 

[Christophe Vanfleteren]

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.

 

[Michael Borgwardt]

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.