-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 3 posts ] 
Author Message
 Post subject: what is the best practise to hand data not found at dao?
PostPosted: Mon Dec 11, 2006 2:14 am 
Newbie

Joined: Fri Dec 08, 2006 3:51 am
Posts: 1
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("from Item where name=?", 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 "results.get(0) "

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 "DataNotFoundException" to service layer.

i am pretty confused here. should I need my own "DataNotFoundException" 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
Edit/Delete Message


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 11, 2006 3:48 am 
Expert
Expert

Joined: Tue Dec 28, 2004 7:02 am
Posts: 573
Location: Toulouse, France
Just a hint about what you do : you seem to be waiting for a row only. In this case, I would use the uniqueResult() method instead.

I'm also using Spring daos, to do this, just do getSession.createQuery("you hql").uniqueResult();

Which version of Hibernate are you using ?

We face the same problem. We decided to wrap the exception in our own LoadException, etc.

Another thing is : if you're using Spring (or another one) automatic tx demarcation, the exception might be thrown after this code, so catching it in the dao would not be useful. The only way we found to workaround this problem at the moment is flushing just before returning the result. This way, data are tried to be synced and exceptions are throw if necessary...

IMO, you should never return an empty list to your service Layer in a case where you meet a problem. Even the DAO should return an exception for not finding the data you asked for.
So, Dao shoud just answer : "I can't find what you want, based on the criteria you gave", and service, with business rules, for example : "the client with this name couldn't be found".

_________________
Baptiste
PS : please don't forget to give credits below if you found this answer useful :)


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 11, 2006 10:33 am 
Expert
Expert

Joined: Tue Jul 11, 2006 10:21 am
Posts: 457
Location: Columbus, Ohio
Batmat is right about using uniqueResult() if the name column is unique for the item table. But, I'm going to have to disagree with the exception advice. :)

You only want to throw exceptions for programatic off normal states. I would not consider a user mistyping a string into an edit box a programatic off normal state. Do yourself a favor and return null. You really don't want to be propogating exceptions through your layers, it just makes a mess of things later and essentially forces you to generate a whole exception hierarchy. If you really want to create a proper exception hierarchy, then knock yourself out, but that will involve DaoException as an abstract Exception, specific DataNotFoundException subclassed from DaoException, trapping the generic DaoException in the service layer and handling specific subclasses. And then what? Rethrow a ServiceException and pass it up the chain to the presentation layer? Which code is cleaner?

Code:
// DAO
public Item getItemByName(String name) {
return result = (Item) getHibernateTemplate().find("from Item where name=?", name).uniqueResult();
}

// SERVICE
...
Item item = getItemByName("joeschmoe");
return item == null ? "No data found" : item.toString(); // or whatever the service layer returns
...


or

Code:
// DAO
public Item getItemByName(String name) throws DaoException {
Item result = (Item) getHibernateTemplate().find("from Item where name=?", name).uniqueResult();
if (result == null) {
    throw new DataNotFoundException("No item was found for " + name);
  } else {
    return result
  }
}

// SERVICE
...
try {
  Item item = getItemByName("joeschmoe");
  return item.toString(); // or whatever the service layer returns
} catch DaoException {
  return "No data found";
}
...

DAOEXCEPTION
public abstract class DaoException extends Exception {
  ...
}

DATANOTFOUNDEXCEPTION
public class DataNotFoundException extends DaoException {
  ...
}



Every time I've tried to generate an exception hierarchies for non-programatic off normal states, it turned out to be a huge pain in the rear, with an exception hierarchy that matches or exceeds the complexity of the layered architecture! Just let your service layer transform the result into something the presentation can display and be on your merry way. I mean, the uniqueResult() method returns null if the data is not found, that should be a clue as to what the Hibernate developers think about throwing an exception in that instance. :D


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 3 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.