Exception handling

[Luc Feys]

Hello,

I have a few questions regarding the handling of exceptions in my project. I have created a three tier application:
*) database layer
*) application layer
*) gui

Now I would like to wrap/translate the database layer exceptions in specific application layer exceptions, so the gui is never exposed to database layer exceptions (which should for example make migration to a SQL database easier).

But this brings up a few questions:
*) Could I create a global Exception handler class that translates all database layer exceptions into app layer exceptions, or would this be a bad programming practice? This would make it easy to wrap all database
exceptions in the application layer the same way, without duplicating code.
Example:

    class someDAO {
        ...
        try {    
            //Some database code
        } catch (RecordNotFoundException e) {
            ExceptionHandler.handleRecordNotFoundException(recNo);
        }
    }
    ...
    class ExceptionHandler {
      ...
      public static void handleRecordNotFoundException(long recNo) 
            throws DataAccessException {
        throw new DataAccessException("Record recNo not found");
      }
    }

*) Most of my database layer exceptions are pretty low level and not very interesting for my GUI. Except for 'RecordNotFoundException'. Now I have one general 'DataAccessException', but I feel a distinction might be interessing. Would it be bad practice to wrap the 'suncertify.db.RecordNotFoundException' in a 'suncertify.app.RecordNotFoundException', so I can give the GUI user the same Exception information without actually exposing any database layer exceptions?

Any thoughts on this are welcome.

Thanks a lot.

Luc

[Mihai Radulescu]

Hi Loc

I have the same problem but I prefer to chain the exeptions using the initCause(Throwable cause) from the Throwable. This feature provides enought information about the exception and its causes.
If you use a global Exception handler you must be shore that it provides enought information about the exception(and its possible cause).
An other point is the logging - if you use it. I use the throwing everytime when a method is terminating by throwing an exception.


Regards,
Mihai