One approach I use is to to subclass application exceptions from an
abstract class that augments Exception with a symptom, context, remedy
and root cause. The application exception can wrap a system exception as
the root cause and supply additional information in the other fields.
This technique is not EJB-specific, but lends itself to EJB apps, given
the obscure remote failures and poor information coming out of typical
EJB system exceptions. Remedy is esp. useful; nothing is more annoying
to a hapless user than "System error" and not a clue as to how to
proceed.
Exception wrapping is fairly common, but I am surprised that I haven't
encountered factoring out the symptom, context and remedy elsewhere. It
is a natural way to format messages consistently and is easy to do. But
of course exceptions are something developers prefer to ignore; it's
those pesky users who insist on meaningful error messages!
Fred Loney
Enterprise Java Consultant
Spirited Software, Inc.
[EMAIL PROTECTED]
----- Original Message -----
From: "Lars Hagrot" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 10:45 PM
Subject: Design Guideline for Exception Handling ?
> Design Guideline for Exception Handling ?
>
> We have a four tier J2EE architecture with a web application, a
session
>
> bean layer, a entity bean layer and an oracle database.
> The system has interactive users. Errors can of course occur in any
> layer. We want to give informative messages to the users about errors.
>
> In the EJB specs there is application exceptions like FinderException,
> CreateException and so on. These will mostly (or only) be thrown from
> the entity beans and may be rethrown by the session bean layer. But
are
> they really useful in the web layer?
>
> Has anybody in this community developed a successful strategy for
> exception handling or can anybody give a hint about good patterns,
books
>
> or papers in this area?
>
> Here is some of my thoughts about the topic:
>
> 1 You can not (do not want to) take care of all types of possible
> exception everywhere in the architecture.
> 2 You do not want a layer to be dependent on exception types in all
> layers below.
> 3 You do not want zillions of exception types and explicit catch
blocks
>
> for all of them everywhere.
> 4 You do not want error messages hard coded where you throw an
> exception.
> 5 You do not want to decorate all interfaces with all kinds of
exception
>
> types because most of the time you do not care about the type of
> exception.
> 6 You almost always want to roll back transactions when an exception
> occured.
> 7 You do want the users to understand what has happend and what to do
> about it.
> 8 You do not want to tell the user there was a
> javax.ejb.XXXXXXException.
> 9 You do want the session bean layer to take care of the transaction
> demarcation (implicitly).
> 10 You have to ensure your session beans throw EJBException if you
want
> to roll back transactions (according to the specs).
> 11 Every possible component shall not declare a special exception
type.
>
> I (we) do have a strategy and a design but I think there is a lack of
> good useful patterns and I want to hear about other peoples oponions.
>
> Regards
> /Lars Hagrot
>
>
========================================================================
===
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email
to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
