Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > How to design an exception architecture in a software?

Reply
Thread Tools

How to design an exception architecture in a software?

 
 
gooperaus
Guest
Posts: n/a
 
      12-30-2003
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
 
Reply With Quote
 
 
 
 
Dave Glasser
Guest
Posts: n/a
 
      12-30-2003
http://www.velocityreviews.com/forums/(E-Mail 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.


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

http://qform.sourceforge.net
 
Reply With Quote
 
 
 
 
Michael Borgwardt
Guest
Posts: n/a
 
      12-30-2003
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.

 
Reply With Quote
 
brougham5@yahoo.com
Guest
Posts: n/a
 
      12-30-2003
Michael Borgwardt <(E-Mail Removed)> 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.
 
Reply With Quote
 
Dave Glasser
Guest
Posts: n/a
 
      12-30-2003
Michael Borgwardt <(E-Mail Removed)> 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
 
Reply With Quote
 
Michael Borgwardt
Guest
Posts: n/a
 
      12-30-2003
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.

 
Reply With Quote
 
Karl von Laudermann
Guest
Posts: n/a
 
      12-30-2003
(E-Mail Removed) (gooperaus) wrote in message news:<(E-Mail Removed). com>...
> 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.
 
Reply With Quote
 
Dave Glasser
Guest
Posts: n/a
 
      12-31-2003
Michael Borgwardt <(E-Mail Removed)> 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
 
Reply With Quote
 
Christophe Vanfleteren
Guest
Posts: n/a
 
      12-31-2003
Dave Glasser wrote:

> Michael Borgwardt <(E-Mail Removed)> 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/...Exception.html
for the details.

--
Kind regards,
Christophe Vanfleteren
 
Reply With Quote
 
Michael Borgwardt
Guest
Posts: n/a
 
      01-02-2004
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.

 
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
CFP - Journal of Systems Architecture, Embedded Software Design(Elsevier), Special Issue on Hardware/Software Co-Design Juan A. Gomez-Pulido VHDL 0 08-24-2009 02:11 PM
2nd. CFP - Journal of Systems Architecture - Embedded Software Design(Elsevier) - Special Issue on HARDWARE/SOFTWARE CO-DESIGN Juan A. Gomez-Pulido VHDL 0 05-24-2009 03:14 PM
collocated architecture versus distributed architecture apngss@yahoo.com Java 3 09-29-2005 07:44 AM
how can I use a signal defined in one Architecture to another Architecture Muhammad Khan VHDL 4 07-10-2003 06:14 PM



Advertisments