Here comes one opinion...
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Lars Hagrot
Sent: den 28 augusti 2001 07:45
To: [EMAIL PROTECTED]
Subject: Design Guideline for Exception Handling ?
1 You can not (do not want to) take care of all types of possible
exception everywhere in the architecture.
Agree.
2 You do not want a layer to be dependent on exception types in all
layers below.
Agree.
3 You do not want zillions of exception types and explicit catch blocks
for all of them everywhere.
Well, exception classes gives you a good "container" for documenting
exceptions, as well as catching them when needed. Having many exception
classes makes your component contracts easier to understand (since they are
part of the interface). I prefer to have a rich set of exception classes
organized in a class hierarchy, such that each tier has one or a few
abstract base exception classes that are explicitly declared in the remote
signatures. The client code may then choose to care about explicit
subclasses or not.
4 You do not want error messages hard coded where you throw an
exception.
I prefer going the standard route - localized resource bundles with property
files. In some frameworks we have extended the MessageFormat functionality,
by binding exception instance fields (and their names) to place holders in
error messages. Then it is natural to bind error message keys to exception
classes. Example:
public abstract BaseEntityTierException extends Exception {
public String entityName;
public Object entityKey;
public MandatoryFieldException(...) {...}
}
public MandatoryFieldException extends BaseEntityTierException {
public String fieldName;
public MandatoryFieldException(...) {...}
}
EntityTierMessages_sv_SE.properties:
Entity.name.Customer = Kund
MandatoryFieldException = Kunde ej spara post av typen {entityName} med
primarnyckel {entityKey} p.g.a. att varde saknas for faltet {fieldName}, som
ar obligatoriskt.
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.
Among the two extreme options: standardize on one exception class per tier
or have one base class per tier with one exception class per message or set
of related messages, I prefer the second one.
6 You almost always want to roll back transactions when an exception
occured.
Yes. Unfortunately, there is no language binding for commit/rollback
semantics in EJB, except for technical failures, which is bound to runtime
exceptions. In practice, you must add code to rollback a transaction, which
makes your components none-composable into higher-level
transactions/components. Before EJB 1.0, I did some MTS projects with J++. I
really felt annoyed by Microsofts way of forcing the programmer to call
setAbort and setComplete, depending on clean or exceptional execution of a
method. First of all, it forced me to write a lot of plumbing code. As usual
with plumbing code, people make mistakes. Secondly, I forced me to have my
BusinessDelegate as a full-fledged transactional component, as a
TransactionOutcomeDecisionStrategy implementation. When the EJB 1.0 spec
arrived, I was happy to read that I'm revealed from commit/rollback
plumbing. At the same time, Microsoft announced COM+ transactions, also with
commit/rollback bound to exceptions. Unfortunately - for some reason I have
a hard time to figure out - EJB 1.1 is half way back to MTS (half way, since
MTS don't even commit).
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).
See 6.
10 You have to ensure your session beans throw EJBException if you want
to roll back transactions (according to the specs).
No, this is only for technical failures. You are advised to throw
application exceptions, and call setRollbackOnly(), in those (99,97% of the)
cases where you want a rollback along with the application exception
11 Every possible component shall not declare a special exception type.
See 3
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.
Agree! Locking forward to the discussion.
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".
