A problem with 3 exceptions from 1 method!!!

Question

I don't like it and I need advice on how to avoid it. I have been given an interface and am required to use ech of its methods. Here is what happened...
The interface declares that when a record is searched for in the database and cant be found then a database exception must be thrown.
When a operation is performed on a record it gets locked with a lock cookie and this cookie must be the same when the lock is released at the end of the operation or a Security Exception gets thrown.
The file accessing itself throws IO exception which ofcourse has to be handled too.
So far I have done the following(data level). I have a general databaseException which is a parent to all database exceptions. This means my Security and RecNotFound exceptions can be caught by one exception as they bubble up the stack. My IOException gets converted to a runtime exception and will be converted back to a checked exception in the GUI layer where I cater for all exceptions (The user does not see them).
Moving on....
In my service layer layer I have a business Exception to all business logic errors. Here is why it gets tricky...
A record can not be booked if it is already booked. So I have a bookedRecException and the booking process involves locking the record(throws databaseException as mentioned). I also catch my RuntimeIOExceptions and throw them in my service layer up the stack as an IOException which gets handled in the GUI.
As you can see this does not look good and I want to fix it. I thaught of making my databaseException into a IOE my service interface methods are all throwing DatabaseException AND IOExceptions.
Edited by: Yucca on Apr 2, 2009 8:37 PM

Answer 1

Yucca wrote:
morgalr wrote:
So what you are saying is: you don't want to deal with all the different exceptions?
No what I am saying Is it's the SCJD and I am trying to avoid messy code with 3 exceptions. I am very much for custom exceptions where having a strongly typed exception tells you enough just by the fact that AlreadyBookedRecordException in your stack explains it all.That is not apparent from you post, what you seem to be saying is that you don't want them. In any case I've never found it messy to handle all exceptions individually, nor have I found it messy to use the method I mentioned.