• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

DAO Class Best Practice Question

 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I suppose this question would apply regardless of whether I was using JDBC or an ORM, but since my DAO is Hibernate based, I'll ask here.

In my DAO class methods, if an item is not found, is it better practice to return null (to my service layer) or throw some type of "not found" exception?

Part of the reason I ask is that I'm trying to force myself to (finally) write unit tests for my code, and I started asking which would be more testable. But, as we all know, good design practices can have many benefits.

Jason
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is more of your application.

Meaning is not finding a record something that might mean you want a whole transaction to rollback, or is it something that might mean, hey that doesn't exist but I can keep going and recover from such a problem.

There is no right or wrong answer to it. Maybe it is use case by use case basis, so you would be better off just returning null. Maybe you hate NPEs and it is a bane to your existence, and you don't want all these if (myRef != null) everywhere then throw an exception. Maybe you think if one small problem occurs then everyone everywhere must fail, then throw a really big Exception, maybe a runtimeException.

Hope that really confuses you more

Mark
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Jason,

Although I am not 100 % sure about this, but still, I think

if the DAO had to load a thing which must exist then it should throw exception. But if we are just checking that whether we have any value for this data in database, then we must not throw an exception.

Actually from the performance point of view, exception cause performance degradation. So I think we should use exception only in the case where we must require them.
And according to some best practice, it is good design in which flow is controlled by exception. So, this thing is also needed to be considered before taking any decesion to whether throw exception or return null.

So in nut shell, it all depends on the usage of the method.
 
Jason Ferguson
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Okay, the general consensus seems to be that throwing exceptions is the way to go.

Unfortunately, my current Generic DAO, which has at least 10 class-specific DAOs extending it, returns Null.

However... I've been wanting to learn Spring AOP, and read an article about the Cukoo's Egg design pattern, which (generally) intercepts calls to older code and redirects to new code. This could be a good excuse to learn it, even if there are simpler ways to do it.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic