0

Can I use spring DataAccessException directly in service layer?. Is this a good practice/design to spread a frame work class in service layer?.

OR

should i catch DataAccessException in dao layer and rethrow it as some more generic Exception?

rohit
  • 602
  • 4
  • 11
  • 24

3 Answers3

1

I think it's fine for the DAO layer to throw that exception. The service layer already knows about the persistence layer, so no additional dependencies are created.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • won't it affect separation of concerns between service layer & dao layer.. What's your approach on it? – rohit May 20 '12 at 11:17
  • There is no separation - it's a one-way relationship, by necessity. The service layer knows about the DAO, but not the other way around. That's fine. – duffymo May 20 '12 at 11:19
  • The service layer knows about DAOs, but it potentially doesn't know about Spring. It wouldn't introduce a new library dependency, but potentially a conceptual one. Unusual in practice, perhaps, but a DAO could conceivably be used in multiple ways... Not sure about this one; still thinking. – Dave Newton May 20 '12 at 11:23
  • The service layer already knows about Spring; it had the DAO injected. – duffymo May 20 '12 at 11:23
  • And what about the scenario if i need to throw DataAccessException again in UI layer...won't it create high coupling in all layers? – rohit May 20 '12 at 11:29
  • You should not be throwing any such thing in a UI layer. I said the service layer deals with the DAO and its exceptions. The UI layer should be going through the service to get what it wants. – duffymo May 20 '12 at 11:30
  • so how to tell UI layer if something happened bad? – rohit May 20 '12 at 11:41
  • Service layer sends a response message to the controller, which then decides what to do. – duffymo May 20 '12 at 12:33
1

It is good to map/wrap the DataAccessException (thrown from DAO layer) into application specific exception hierarchy (in service layer) so that the dependent/calling layer has to just deal with your application specific exception classes.

Ahamed Mustafa M
  • 3,069
  • 1
  • 24
  • 34
  • I disagree with this. The service layer might map it, but there's no value in the persistence layer wrapping its own exception. The service layer ought to catch it and handle it. Wrapping it only loses information. – duffymo May 20 '12 at 11:20
  • I meant that the service layer should wrap it.Since the question is on the service layer , I didnt explicitly mention it.Also, I dont think wrapping will lose the exception trace. – Ahamed Mustafa M May 20 '12 at 11:27
  • No, the service layer should not wrap it. It should handle it and not re-throw. That's very different. – duffymo May 20 '12 at 11:31
  • What sort of 'handling' do you expect if a subclass of DataAccessException like DataAccessResourceFailureException/UncategorizedDataAccessException is thrown ? – Ahamed Mustafa M May 20 '12 at 11:38
  • so, how to tell UI layer that something bad happened as you are saying "It should handle it and not re-throw". – rohit May 20 '12 at 11:38
  • Service ought to send info to the controller for rendering, but it should not be an exception. UI needs to be told to display either an error page with a friendly message or something else, but certainly *not* an exception. – duffymo May 20 '12 at 11:44
  • You're all assuming that wrapping an exception is somehow helpful. There has be a "buck stops here" layer before UI. – duffymo May 20 '12 at 11:44
0

Personally, I catch all checked exceptions in the service layer and throw my own ServiceExceptions initializing them with the catched exception. This way, the exception information is not lost and Controllers don't need to deal with low-level exceptions. But there's no need to do this in the DAO layer.

There's a pretty good chapter on exception handling in "Effective Java" (J. Bloch), it's a good read, as well as the rest of the book. Item 61 deals with this question.

http://books.google.de/books/about/Effective_Java.html?id=Ft8t0S4VjmwC