and another opinion...
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Lars Hagrot
Exception handling in entity beans is very poor. Because ejbStore and
ejbLoad are methods implemented from a defined interface, in order to add
new exceptions to these methods, you must:
1. Subclass EntityBean interface and extend with your exceptions. Problem
occurs when you want to add one more exception to the list.
2. Throw exceptions from the entity bean as a subclass of RuntimeException.
This violates the spec.
3. Somehow wrap the exception you want to throw from the entity bean in a
valid exception. Then unwrap and rethrow in the session bean.
There are some serious problems with throwing any kind of remote exception.
Some containers immediately abort the transaction (at the point of the
runtime exception), preventing the bean developer from catching the
exception. Also, runtime exceptions are automatic rollbacks.
Now why would you want to add exceptions to these methods? Plenty of
reasons. ejbRemove and ejbStore, especially, are places where validation
exceptions will often be thrown. ejbStore will often cause concurrency
exceptions. For a truly robust client, it is necessary to throw more in
these methods.
We have painfully come to the conclusion that entity beans are a bust. They
contribute nothing to the architecture. Most of our two year-old
architecture is full of comprimises we have had to make because of entity
beans. On the surface it seems like a valuable technology, but when it comes
to functionality necessary for a real-world (stress robust...validation,
concurrency, etc.) application it falls short, IMHO.
> 1 You can not (do not want to) take care of all types of possible
> exception everywhere in the architecture.
umm... It's obviously true since many exceptions can originate via the
server, database, etc. You *should* take care to document (via a throws
clause) any exceptions that your method do throw.
> 2 You do not want a layer to be dependent on exception types in all
> layers below.
Not sure what you mean here.
> 3 You do not want zillions of exception types and explicit catch blocks
> for all of them everywhere.
No....zillions would be too many. :-)
> 4 You do not want error messages hard coded where you throw an
> exception.
I would like to see the alternative. Keep in mind that hardcoding includes
the use of resource bundles, since you have to hardcode the key. Also,
resource bundles are not exactly portable between app servers.
> 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.
Totally disagree. If all you want to convey is "the operation did not work"
then fine, create some global exception class and throw it everywhere.
> 6 You almost always want to roll back transactions when an exception
> occured.
OK....*almost* always. A rollback occurs automatically on any
non-application exception. It is up to the bean developer to decide when a
rollback should occur otherwise. There are plenty of examples where the
rollback is controlled by the session bean wrapper class, and an entity bean
simply coughs up exceptions without rollback.
> 7 You do want the users to understand what has happend and what to do
> about it.
ok...
> 8 You do not want to tell the user there was a
> javax.ejb.XXXXXXException.
ummm... I think I agree. I want to tell them, "Salary must be greater than
$0.00".
> 9 You do want the session bean layer to take care of the transaction
> demarcation (implicitly).
most of the time, but what's the realtionship to exceptions?
> 10 You have to ensure your session beans throw EJBException if you want
> to roll back transactions (according to the specs).
Where in spec!? EJBException is a runtime exception, and it is never
(necessarily) declared in a method signature.
> 11 Every possible component shall not declare a special exception type.
Component? Method? Explain how you will handle validation and concurrency
exceptions. What about unique index violations? or foreign key violations?
Thanks for bringing this important topic up. I just finished a document on
exception handling in our EJB framework. I would be happy to share portions
of it relating to entity beans.
jim
===========================================================================
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".
