what is the best practise to handle data not found at dao? spring, following, situation, friends

amy

hi,

I would like to seek for advice on how u friends are handling a situation whereby data is not found at Dao.

e.g. i have the following method in my ItemHibernateDao implementation:

public Item getItemByName(String name) {
List results = getHibernateTemplate().find(quot;from Item where name=?quot;, name);
return (Item) results.get(0);
}

if NO data is found, very nicely, spring will return a empty List after find() . YES, it will crash my return quot;results.get(0) quot;

after reading a number of examples. I got the following choices:

1)at dao, check if results.isEmpty(),  then throws EmptyResultDataAccessException and catch at Service layer. rewrap with my own new DataNotFoundException and throw it to MVC

2)at dao, check if results.isEmpty(),  then return a null back to service layer, then throw new DataNotFoundException to MVC

3)at dao, change the return signature to List, just throw empty list back to service layer, check if empty, throw new DataNotFoundException to MVC

4)at dao, check if results.isEmpty(), then throw new quot;DataNotFoundExceptionquot; to service layer.

i am pretty confused here. should I need my own quot;DataNotFoundExceptionquot;  at all? should I throw it at dao and catch at service layer? or throw it at service and catch  at MVC layer?

how about just  rewrap and throw  any spring exception (.e.g DataAccessException or EmptyResultDataAccessException) all the way from  DAO level,  (simply throw all  DataAccessException at service), and only catch at MVC layer ??

pls advice. thanks for much

~thinkboy

It's really a business decision.  If no item is found is that considered to be an error (i.e. unrecoverable), or is it just a case of searching for a unique object, and telling the user that there is none and please try again (i.e. recoverable)?  The only guidance I might offer is that your DAO should stay as low level as possible, so that the higher tiers can implement the business logic.  Then it is just a question of the contract that your DAO has with the service layer - again it's up to you, there are no rules about whether you should return null or throw an exception of a particular type.  If the behaviour is part of a contract, it probably doesn't make sense to be throwing array index out of bounds exception, but your service layer might be happy with a more specific exception, or indeed with just receiving a null item.

I would agree with David.  I wouldn't throw index out of bounds, if someone is debugging later and this crops up it can be confusing (I hate problems like this).  Depending on how you want to caller to proceed either exception or null object would be my choice.

I agree with David.
In case your item name is unique or is even the primary key I would implement the same behaviour as in your DAO's getItemById() method. If you use Spring's dao support this might throw an ObjectRetrievalFailureException (e.g. when delegating to HibernateTemplate#load) or simply return null (when delegating to HibernateTemplate#get).
Furthermore, you should throw a different exception if the list retrieved from the db contains more than 1 entry, and not simply ignore this case since it is probably an indication of inconsistent data in the db.
Also consider the use of org..dao.support.DataAccessUtils (though I would avoid the requiredUniqueResult method in most cases since it throws an IncorrectResultSizeDataAccessException for empty lists which seems not appropriate for your use case).

Werner