 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Struts - A MVC web framework | | Tomcat - JSP/Servlet container | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | | JSP - A mailing list about Java Server Pages specification and reference | |
Struts & Hibernate
|
|
|
| | | Exception Handling in J2EE project | Exception Handling in J2EE project 2003-12-08 - By Dario Geier
Back
You can through any kind of RuntimeException for the transaction to rollback,
not just EJBExeption
-- --Original Message-- --
From: BOWMAN, James [mailto:James.Bowman@(protected)]
Sent: Monday, December 08, 2003 11:28 AM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: [J2EEPAT-INT] Exception Handling in J2EE project
To ensure the transaction is rolled back, you will either need to throw a
subclass of EJBException or call the setRollbackOnly method on the context
object.
-- --Original Message-- --
From: Prasenjit Narwade [mailto:PrasenjitN@(protected)]
Sent: 08 December 2003 06:58
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: [J2EEPAT-INT] Exception Handling in J2EE project
Hi Sridhar,
Thanks for the reply. However what I would specifically want to know
is, suppose I encounter an exception, say InsufficientBalanceException in
DAO layer and if I catch the same in my Session Bean , do I *need* to throw
a subclass of EJBException to ensure that my transactions (container
managed) are rolled back or throwing any other exception will serve the
purpose.
Regards,
Prasenjit
-- --Original Message-- --
From: Kancharlapalli,Sridhar [mailto:kanchars@(protected)]
Sent: Sunday, December 07, 2003 10:45 PM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Exception Handling in J2EE project
Hi,
Designing custom exceptions are a sort of must in a framework so that we
throw/catch exceptions specific to the business process so that the client
and other business components are aware of business violations and
exceptions.
Custom checked exceptions would contribute to the most of the exceptions we
define in our framework. Creating wrappers over existing exceptions wouldn't
serve the purpose in most of the cases except to complicate the process.
The main design consideration would be where to handle a specific exception,
as exception's consume memory and may affect the overall performance of the
system it is always good to spend enough time on designing exception
handling.
For example:
Suppose we take the case of a Entity Bean:
Since the entity bean's are bundled with data logic, custom exceptions such
as FieldRequiredException can be raised from the bean. And also SQL
exceptions which indicate Duplicate records or any other such constraints
can be rethrown as a business exception from Entity Beans (with custom
messages).
With the case of a Session Bean:
Most of the business exceptions are thrown from Session Bean as Business
Logic is bundled in them. Security Exceptions are easier to describe, if the
session bean is used as a Facade then it is a good idea to bundle security
logic in them.
With the case of Business Delegate:
This can be a place where non-business specific exceptions or unchecked
exceptions can be caught and re-thrown with custom messages. Since these
exceptions do not carry any importance to the business process (but might
affect a process indirectly), so handling them at the session or entity
level would just be inappropriate, but from the client point of view these
exceptions are to be notified with readable messages.
Hope above description helps you, it is just my observations and experience
I am sharing with you and any suggestions are welcomed.
-Sridhar Kancharlapalli.
Hi All,
What is the best Hierarcy (framework) for handling exceptions in a
J2EE project.
I am thinking of some roughly the following Hierarcy consisting
broadly of three categories :
+ MyApplicationException extends Exception ( For handling bussiness
exceptions.)
- InsufficientBalanceException
- InvalidPasswordException
- etc.
+ MySystemException extends RuntimeException (Non bussiness
exception, exception due to System problems)
+ MyEJBException extends EJBException (Not too sure if this is
required)
My question is :
1. Is this approach correct ?
2. My application flow consists of
ActionClass calls BussinessDelegate calls SessionBean calls
DAO and
ActionClass calls BussinessDelegate calls SessionBean calls
EntityBeans
How should the exception for take place. Should it be something
like this:
DAO throws some ApplicationException ...
caught by SessionBean thrown as some EJBException ......
caught by BussinessDelegate and do some handling
Regards,
Prasenjit.
===================================================================Companion
Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)
===================================================================Companion
Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)
===================================================================Companion
Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.547 / Virus Database: 340 - Release Date: 02/12/2003
===================================================================Companion
Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
===================================================================Companion
Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
|
