Hi,

I am just starting using Hibernate and got a question about the HibernateException.

Why is HibernateException an unchecked exception ?

In the Wiki is noted that exceptions should be handled in some higher-level layer.

But when using Hibernate in a Session-Facade (CMT) I think it is desirable to throw an ApplicationException instead of a SystemException to the client in case of an (low-level) error.

Some methods like "load()" throws an HibernateException when no result was found (NULL), others like "get()" do not.

Should I simply catch HibernateException and throw something like "BusinessManagerException" as ApplicationException or just rethrow the HibernateException.

Would be interesting to know how you handle occuring HibernateExceptions in a Session-Facade.

Regards
Jan Zimmek

HibernateExceptions should certainly not be application exceptions because ... well ... they have nothing to do with "application".

They should be runtime, so that they force txn rollback.

Hi,

you are right.

When I thought about throwing an ApplicationException (checked, not Runtime) I totally forgot that an existing TX would not be rolled back.

Regards
Jan Zimmek

Gavin,
I support your statement about HibernateExceptions when they represent low-level problems with the datastore or the mapping mechanism. Such exceptions are probably caused by infrastructure malfunctions or development bugs and are therefor useless for a client. They can smoothly be converted to a RemoteException or EJBException (by the EJB container).
On the other hand, i assume some HibernateExceptions can be usefull for a client. Particulary the constraint-violation-specific subclasses of JDBCException (e.g. representing a Unique Constraint) are sometimes usefull since they represent a recoverable problem which should be handled by the client (and which are for performance reasons not already validated in code). These exceptions shouldn't be converted to a RemoteException or EJBException (since it's not the responsability of the client to inspect the cause of this RemoteException).
I'm aware of the evilness of checked exceptions and I'm not advocating to re-introduce them (EJB3s EM will also throw unchecked exception) but I'm looking for a way to convert some HibernateExceptions in some cases to checked application exceptions (which will also mark the tx for rollback). My solution was to write a wrapper around the Hibernate Session which transforms the Hibernate exception into the correct application exception but this only works for the operations which are implicily called on the session and (I assume) not for the dirty checking mechanism. Correct?
- Is it possible to intercept the runtime exception which will be thrown when the first level cache gets synchronised with the DB => when the transaction commits (if the CMT was started on the session facade, the control will be already given back to the container)?
- What is your view on this kind of exception handling, based on your experience with Hibernate and in the EJB 3 expert group?

Thanx in advance,

Stijn Janssens

"Particulary the constraint-violation-specific subclasses of JDBCException (e.g. representing a Unique Constraint) are sometimes usefull since they represent a recoverable problem which should be handled by the client (and which are for performance reasons not already validated in code)."

Wrong

christian,

Why is my statement wrong?
I'll give a short example:
Consider a lottery game for which a client can pick 6 numbers. Each combination of numbers can only be assigned to one person. If a person picks an already-assigned combination, a specific error message should be shown and the user should get a chance to try again.
A lottery management system (ejb-module) containes the core functionality for registering the bets for all customers. Since the combination of numbers should be unique, a unique constraint is provided in the database.
In this case, it is possible to check the constraint in the EJB-module by launching a DB search before attempting to persist the bet. (I think this is were the validation belongs since it's a business constraint...)
However, if we add the functionality to perform bulk-bets (10000 combinations of numbers in one call on the system interface), it won't be performant to check the constraint (10000 times) before persisting this bulk bet. Isn't it more convenient to use the DB constraint instead and convert the specific JDBCException to an appropriate application exception?
Furthermore, if I use the business validation instead of the DB validation and someone (other tx) adds the same combination between the end of my validation and the end of my transaction, this would still result in a Unique Constraint exception, altough my validation was succesfull... correct?

Thanx for the reply,
Stijn