HI

i'm currently working for an Application with uses Spring and Hibernate . Also we are following layered architecture .
in this my business logic resides in a ServiceImpl which interacts with a repository where it holds a intelligence for fetching and storing persistence data .

i'm using HibernateDAOSupport for all my repositories . so i need to know how to handle exception for the following scenarion say :

public person findByPersonUId(Long personUid) {
List list = null;
String query = "";
list = (Person ) getHibernateTemplate().findByNamedParam(...")

if(list!= null) {
return person ;
}

in this case even though if there is a problem ,a null value is returned . Is there any need for catching any exception out here if so what exception in need to catch .

currently i'm follwoing this
catch(Exception e) {
log.wrtie(""");
throw new PErsonNotFoundException ---> to service layer
}

is this approch right . kindly validate my assumption

I assume you are using Hibernate3 which throws RuntimeExceptions instead of checked exceptions. Your approach looks fine to me, except that I think you should catch HibernateException or Throwable instead of Exception: if you only want to catch Hibernate problems, HibernateException or one of its subclasses are the ones to use; if you want to catch and log everything, in my opinion Throwable is the right choice. You also might consider moving the logging into the constructor of your own exception so that you can't forget about it.

Normal java wisdom says that you catch the smallest group of exceptions that you want to handle (and thus expect to encounter): anything else should be handled at the highest error-catching level. You almost never want to catch Throwable, because that catches Errors too, and those are for things like linkage errors, virtual machine errors, and other stuff that you probably do want to barf about (after all, if someone deletes rt.jar while your programme is running, not even your error logging code is going to work).

Catching Excpetion is almost as bad, because that includes things like SecurityException and NullPointerException, genuine programming bugs. Again, no amount of logging is going to fix that. You would usually only want to catch these at the top level of a high-availability app, or during testing.

You can take the lazy option of catching HibernateException, but that means that you're trying to recover from things like TransactionExceptions and NonUniqueObjectExceptions, which again are programming bugs. Not recommended for professional applications: these should be caught outside of normal programme flow, at a very high level, so that the app can be restarted or core dumped. This is what I do, though I do it only a few levels higher, where I dump the current session, log stuff to file, inform the user, and create a new session to try to gracefully recover what I can.

The most correct thing to do is to do all possible negative tests, see what exceptions are thrown due to genuine user error, then write business logic to prevent calling hiberante code in any case that would cause it to barf. This is feasible in companies with good test regimes, but for the rest of us it's just too much overhead.

There are all sorts of articles on how and when to catch exceptions, but this summary should do for the average hibernate user: catch HibernateExceptions.