We are using WLS6.0, and implementing an application wide error handling.
Our layers are...
JSP->PageBeans->Business Logic->Data Acess->Database
...and the plan is for exceptions to be handled where possible, or throwing them further up the architecture where appropriate. For example, if the Data Access layer has problems connecting to the database, this is something the user should know about (their data cannot be entered into the database), so we are passing that exception all the way up the architecture (all the methods will probably throw SQLException). Then the web container recognizes this (define the exception in the web.xml) and the user gets a (well-worded) web page telling them there has been some kind of database error.
Does this sound resonable? The only concern I have really is with the passing of the exception through many architectural layers. Lets say we want to rebuild the business logic as Session EJBs, what will we have to do to handle this type of exception handling.
Thanks in advance,
Your solution is very sensible to th extent of propagation, and is required in a multi-layered architecture. However, a better approach is to identify the exceptions that are meaning at a given level. For instance, a web user does not care about a JDBC/SQL exception. It does not make sense at the end user level.
As you move up the layers, the meaning of an exception might change. For instance, an SQLException at the JDBC level may mean an illegal operation on an EJB, which could mean an incorrect data entered in a form. In this case, the SQLException should not result in a HTTP error page, it should instead be treated as a valid use case variation, and the user should be informed of what to do. In some cases, you may implement alternative flows in case of implementations, and the user may never see an error.