• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Exception handeling at different layer!

 
Muhammad Ahsan Jamshaid
Ranch Hand
Posts: 59
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,
My apps design has the following layer: JSF(front-end) -> Business Delegates (POJO) -> EJB3 (Session Facade) -> POJO (DAO) -> Hibernate --> DB. Now i am little confused for exception handeling. I have following approaches in mind.

1- Propogate my exceptions from Hibernate all the way to business delegates and handel all of them there. I am not sure this will be a good approach. But it will allow my to have one place to handel all exception.

2- Handel exception at differnet levels. DB related expceptions IN Daos, Logic and EJB related exceptions in Bussiness Delegates.

Please suggest me better of these or purpose a new suggestion.

Thanks

 
Hong Anderson
Ranch Hand
Posts: 1936
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Muhammad Ahsan Jamshaid wrote:
2- Handel exception at differnet levels. DB related expceptions IN Daos, Logic and EJB related exceptions in Bussiness Delegates.

It might not directly related to your question, but how DAOs handle DB related exception?
 
Muhammad Ahsan Jamshaid
Ranch Hand
Posts: 59
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i mean exception thown at database acess denied or lost connection kind of things...
 
Deepika Joshi
Ranch Hand
Posts: 268
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My apps design has the following layer: JSF(front-end) -> Business Delegates (POJO) -> EJB3 (Session Facade) -> POJO (DAO) -> Hibernate --> DB. Now i am little confused for exception handeling. I have following approaches in mind.


Hello Muhammad,

You could use any of the combination (DAO/Hibernate or JPA Entity). I am curious to know the reason for preferring of DAO+Hibernate instead of JPA Entity (Java Persistence Entity).

Thanks.


 
Muhammad Ahsan Jamshaid
Ranch Hand
Posts: 59
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Joshi,
You could use any of the combination (DAO/Hibernate or JPA Entity). I am curious to know the reason for preferring of DAO+Hibernate instead of JPA Entity (Java Persistence Entity).

Right now i am have 2 reasons, Firstly, i am gettting this architecture in lagecy and secondly i am very less fimilar with JPA Entity. But surely i will look into JAVA PERSISTENCE ENTITY in detail for future concerns.

Well I am not getting the answers to my real concern. Can any one Share his experience ?
 
Amandeep Singh
Ranch Hand
Posts: 850
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i will go with approach 2.
 
Muhammad Ahsan Jamshaid
Ranch Hand
Posts: 59
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Amandeep!
Thanks for reply. any supporting comment for approach 2.
 
Amandeep Singh
Ranch Hand
Posts: 850
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
2- Handel exception at differnet levels. DB related expceptions IN Daos, Logic and EJB related exceptions in Bussiness Delegates.



Handling exceptions at different levels ensure that the responsibility tasks keep separated. you won't end up in catching the sql exception in business logic
which is undesirable. As it will also confuse during bug tracking. it would be best to deal with sql exceptions in DAO.

As responsibilities have been separated why not the exception handling. otherwise it would end up in messy code.

 
Nail Ünlü
Greenhorn
Posts: 1
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Amandeep Singh wrote:
2- Handel exception at differnet levels. DB related expceptions IN Daos, Logic and EJB related exceptions in Bussiness Delegates.



Handling exceptions at different levels ensure that the responsibility tasks keep separated. you won't end up in catching the sql exception in business logic
which is undesirable. As it will also confuse during bug tracking. it would be best to deal with sql exceptions in DAO.

As responsibilities have been separated why not the exception handling. otherwise it would end up in messy code.



The messy code comes when you have your try/catch statements spread all over your code ;-) DB related exceptions should be catched by an interceptor at DAO level or a AOP-module
that catches those nasty SQLExceptions and wrappes them to an internal exception (extended by a RuntimeException) and rethrows them.

Those unchecked exceptions can then be catched with the principle "throw early, catch late" at the highest level (being the web tier). In 99% of the case you cant really react to a SQLException
as most of those exceptions are so fatal, that there's no recovering possible from those exceptions at runtime (constraint violations, non existing rows etc. etc.).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic