0

In our app, these are the layers used:

Rest Service Endpoint Layer --> Business Layer --> DAO --> ORM

Now, each layer translates its exceptions appropriately and sends them to the next layer. For example, DAO Layer creates a DaoException and throws to Business Layer, Bussiness Layer translates this to BusinessException which throws it to RestService Layer where it is handled by a cxf mapper (okay, not really in RestServiceLayer).

We have put @Transactional on the methods of Business Layer. So, if an exception happens at commit, the exception will be fist seen only in the Rest Service Endpoint Layer. Now, I will have to check for transaction commit related exceptions(eg. RollBackException etc.) in the topmost layer (Rest Service Endpoint Layer), which would kind of defeat the purpose of each layer translating the exceptions for the next layer.

What would be a good way of dealing with this situation? Should I not translate exceptions at all and handle all of them only on the topmost layer?

TJ-
  • 14,085
  • 12
  • 59
  • 90

1 Answers1

0

Write an annotation-driven AOP point-cut on exception thrown and have that translate if you really want to translate and apply the annotation to your business layer. But I would also recommend against translating - what are you gaining by having the translation?

Καrτhικ
  • 3,833
  • 2
  • 29
  • 42
  • I have seen posts on SO and otherwise which say that it is meaningful to translate exceptions from one layer to the other which would leave only a limited set of relevant exceptions for the subsequent layer. I might have missed some fundamental point though. A suggestion like [this one](http://stackoverflow.com/questions/9256255/handling-dao-exceptions-in-service-layer) – TJ- Feb 01 '13 at 20:04
  • Also, I am actually not using @ Transactional but @ MyTransactional (because I am not using JPA but a custom wrapper written by one of the teams in my company. They don't support @Transactional yet) which is already AOP point-cut and I am throwing an exception from there which is to be handled somewhere consistently in accordance with the rest of the exception handling. – TJ- Feb 01 '13 at 20:06
  • I guess it goes to your philosophy of exceptions. An exception should not be something that one can "recover" from. I.e., don't transmit valid business cases via exception. I use exceptions only to get out of whatever I was trying and abort the operation and convey to the caller that whatever you tried failed and pass enough information to debug/troubleshoot/fix etc. Think every exception is an unchecked exception. So why do I care what the exception was. PersistentException vs. 10 flavors of actual Hibernate/JPA exceptions. How am I handling it differently? – Καrτhικ Feb 01 '13 at 20:22
  • I would agree to what you are saying but I think I will find it really difficult convincing people in my org to break from the philosophy that is being practiced :-| – TJ- Feb 01 '13 at 20:28