• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Can you throw too many exceptions?

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello JavaRanch,

I've been plugging away on the SCJD project for a fair while now, and while I've found JavaRanch invaluable, this is my first post.

I'm doing Bodgitt and Scarper and in my suncertify.db package have the Data class as well as a DBAdapter which implements a DBClient interface.

In the DBAdapter class I have the following declaration....



My question is, am I throwing too many exceptions? Should I be wrapping some of these (ie BookingException, RecordNotFoundException, DBRecordException, SecurityException) in a DBClientException or similar?

Many thanks
Simon

[Andrew: code wrapped]
[ July 28, 2004: Message edited by: Andrew Monkhouse ]
 
Simon Quirke
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The other option I forgot to mention was:

Could I create a class DBException, then extend the appropriate exceptions (BookingException, DBRecordException, RecordNotFoundException, SecurityException) from the DBException class so I only need to declare...



Thanks
Simon
 
Ranch Hand
Posts: 532
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi Simon:
IMO I don't see a problem in thrown many exceptions as long as each exception represents a unique exceptional condition and should be handled differently than other exceptions. However, you should be careful in throwing too many exception. You get to think about other programmers who might use your objects. They have to catch too many exceptions...Would you like to deal with this kind of object??
One way to minimize this is too gather similar exceptions and wrap them in just one. For example: If your code throw FileNotFoundException and SocketException, then you should wrap both of them in an IOException passing the oppropriate message.
I hope this help
 
Ranch Hand
Posts: 197
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

If your code throw FileNotFoundException and SocketException, then you should wrap both of them in an IOException passing the oppropriate message.



Why? They are both I/O exceptions already.
The thrower needs only to declare throws IOEx.
The catcher needs only to catch IOEx.
If the catcher needs to clarify which they can catch the subclass.

I don't see any advantage in wrapping the Exception.
 
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree. Multiple exceptions is OK. It's documentation. Plus it's a good reminder to the developer that when they build their javadoc, just how many @throws entries they need to provide.

RK
 
Hanna Habashy
Ranch Hand
Posts: 532
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
mike:
The advantage in wraping similar execptions is it makes the code cleaner and easier to understand. Insteaded of throwing 10 exceptions in your method, and provide the documentaion to all of them, IMO it is much cleaner to only throw 2 or 3, passing to them the oppropriate messge throw chaining, so you don't loose any valuable information.
 
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Simon Quirke:
Hello JavaRanch,

I've been plugging away on the SCJD project for a fair while now, and while I've found JavaRanch invaluable, this is my first post.

I'm doing Bodgitt and Scarper and in my suncertify.db package have the Data class as well as a DBAdapter which implements a DBClient interface.

In the DBAdapter class I have the following declaration....



My question is, am I throwing too many exceptions? Should I be wrapping some of these (ie BookingException, RecordNotFoundException, DBRecordException, SecurityException) in a DBClientException or similar?

Many thanks
Simon



There isn't too many exceptions, it's the code you have to write and someone else to maintain. If you have so many exceptions, then maybe something is wrong with the assumptions.

[Andrew: wrapped code]
[ July 28, 2004: Message edited by: Andrew Monkhouse ]
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, there are too many exceptions, imagine the code at the other end



Code used for exageration purposes, and please ignore that man behind the curtain.

Mark
 
Robert Konigsberg
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If your exceptions inherit from a common base then the catch() clauses become simpler.
 
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

There are a lot of exceptions that can occur in the two phases of the
project: (1) connecting to the database, opening the database file, or
both, and (2) using the data access connection to read and write the
database.

There are very intelligent and experienced individuals who have weighed
in that there were too many exceptions in one of the examples above.

Also, there are basically two different strategies: (1) where run-time
exceptions are predominantly thrown, and (2) where checked exceptions
are predominantly thrown.

I'll address the case where checked exceptions are predominantly thrown.
And, I'll address the case where we are attempting to open the database
file. There are many errors which can occur, and each specific case when
reported to the user in English allows the user to take action to attempt to
address the error. Therefore, I am inclined to recommend that each
individual exception be thrown; also, that these individual exceptions, for
the most part, be part of a hierarchy of exceptions, so that the client
programmer is free to catch a more general exception type. But for that
client programmer who needs to convert the exception to English, throwing
the more specific exceptions may be better. Of course, one might say that
the exception, when thrown, already should have English text describing
exactly what the exception is, and under this case, the client programmer
might not need to catch each individual exception, but could catch a super
class. [An interesting case would be what would happen if the exception
message in "English" had to handle an audience which may speak "French",
or "Italian" or "Russian"; would this change the answer to your question?]
Again, though, if the individual exceptions are listed in the method, the
client programmer can base a plan of action knowing exactly which
exceptions will be thrown, and this may be valuable (or perhaps not?).

Another reason I'd throw the individual exceptions, is that you might have
one super exception, and there could be ten subclasses of this exception,
but for a given method, it might only throw 5 subclasses of the super
exception; by throwing the individual exceptions, the client programmer knows
which five exceptions might occur. Again, some very intelligent and expert
Java individuals have given advice contrary to this, and thus my response
might be considered more a learning response (for me), and could very well be
incorrect; or, perhaps, there is wiggle room, and additional context which
needs to be known for a given case before deciding which path is best, or
perhaps its half of one and half of another.

Thanks,
Javini Javono
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Robert Konigsberg:
If your exceptions inherit from a common base then the catch() clauses become simpler.




True, if you handle them all the same way. However if you want specific ways of handling each type, then no you can't do that.

It really is a semantics on Exception handling, and there isn't one absolutely correct answer.

My Opinion, is that Exceptions that the throwing class can handle on their own, must do so, and those that they can't should wrap/chain the exception into a "layer" defined Exception, then throw that up the calling chain.

For instance if this was in the Data Access layer, and there are exceptions like, FieldNotFoundException, TableNotFoundException, NoRecordFoundException, InvalidQueryException, etc, then the Data Access Layer will catch these exceptions, and in each catch, wrap/chain them into a DataAccessException, and just throw the DataAccessException.

Mark
reply
    Bookmark Topic Watch Topic
  • New Topic