For the function of session, save, update, delete, load, why not the exact exception is thrown but instead just the HiberateException is thrown??

e.g. for the session.load(), the exact exception ObjectNotFoundException is thrown for the absent of the object. I think it is better than the parent class exception HibernateException so that we can determine exactly what is the problem is and do the corresponding work.

Regards,
William

You can always catch specific exceptions like ObjectNotFoundException if you want to. But the Session methods need to throw the base class HibernateException, as there can be other kinds of failures too, for example JDBC exceptions on load.

Even if the method signatures declare the base exception, you can expect specific subclasses to be thrown. That's a common pattern in API design. It helps to mention important exception subclasses in the corresponding method javadocs, though.

Juergen

Does anyone have a list specifying the exception subclasses thrown from various session methods? The javadocs do not cover this well at all...

Also - is it true that if an exception is thrown (no matter what the reason), the session is essentially unusable from that point on?

That would mean that exceptions are hidden semantically (was it a database connection error, or was my object stale?) and sessions are useless after such an event and you might as well generate a new one automatically so it almost doesn't matter what the exception was in the first place...

This is important since my app cannot have "visible" dependencies (in a developer sense) on Hibernate, so I would like some additional knowledge about what goes wrong. If I have to introspect on each exception - I guess that's what I'll have to do.

Any help or pointers would be appreciated! Thanks!

BTW - I don't agree that just declaring the base exception is an acceptable API design pattern. Granted, it makes it easier to code and "ignore" exceptions, but it does not help in facilitating proper exception handling. It allows the programmer to skimp... a gross (and maybe slightly unfair) analog would be if the entire Java API simply returned "Exception" - sorry, something went wrong, but we'll make you find out what it was.

using session after an exception was thrown is at your own risk. It's very complicated to cover session consistency in such cases because of 1st and 2nd level cache.