It isn't that Entity beans are not designed to handle the error. The problem that JDBC was not designed to handle this type of error. There is only one exception in the java.sql package. There is no generic way to determine the cause of a database error, so you will end up with database specific code in your implementation. For example, you will catch a vendor specific exception or parsing the exception message. This is why a SQLException is considered catastrophic.
-dain > -----Original Message----- > From: Bill Pfeiffer [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 16, 2002 8:49 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] Passing Business Exception to Client > > > In my situation, I just have a field that has a unique > constraint on it, but > I would like to allow my user to put in this field whatever > they would like, > as long as there are no duplicates. From a coding perspective, the > constraint failure is THE place to catch this, not with my > own attempt to > check the constraint in code. > > I guess what I'm hearing is that Entity Beans are not meant to handle > database constraint errors (or that a constraint violation is > catastrophic > so code to avoid it). Coming from a client server backround > where, in this > case, the issues seem to be the same, I find this kind of odd. If the > violation was a foriegn key constraint, I could kinda > understand the "code > it right so it doesn't happen" stance. But a unique > constrained column > value seems like a very reasonable thing to allow the db to > determine and > report back to a user. > > Thanks for the response, > > Bill P. > ----- Original Message ----- > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, January 16, 2002 8:50 PM > Subject: Re: [JBoss-user] Passing Business Exception to Client > > > > On 2002.01.16 20:25:31 -0500 Bill Pfeiffer wrote: > > > How then do you catch db referential integrity errors and > repackage them > > > in > > > a > > > user friendly manner? I'm not really talking about > business logic per > > > se, > > > but rules that are enforced by the database that need to > be communicated > > > back to the client. > > > > > > Or am I missing some big picture thing? > > > > > > > I always figured if the referential integrity constraints > were throwing > > exceptions due to attempts to violate them, that meant I had made a > serious > > logic error in my programming. Perhaps such exceptions need to be > > communicated to the programmer, rather than the client. > > > > david jencks > > > Bill > > > > > > ----- Original Message ----- > > > From: "Dmitri Colebatch" <[EMAIL PROTECTED]> > > > To: "Bill Pfeiffer" <[EMAIL PROTECTED]>; "JBoss-User" > > > <[EMAIL PROTECTED]> > > > Sent: Tuesday, January 15, 2002 12:39 AM > > > Subject: Re: [JBoss-user] Passing Business Exception to Client > > > > > > > > > > in short, you dont. application logic shouldn't be present in > > > > ejbLoad/ejbStore methods. the idea is that you write > load/store stuff > > > once, > > > > and application logic many times. you should throw the > exception from > > > the > > > > method that violated the state (if that is what the exception is > > > about). > > > > > > > > hth > > > > dim > > > > > > > > ----- Original Message ----- > > > > From: "Bill Pfeiffer" <[EMAIL PROTECTED]> > > > > To: "Olaf Strozyk" <[EMAIL PROTECTED]>; "JBoss-User" > > > > <[EMAIL PROTECTED]> > > > > Sent: Tuesday, January 15, 2002 3:54 PM > > > > Subject: Re: [JBoss-user] Passing Business Exception to Client > > > > > > > > > > > > > OK, now I'm confused. Using JBoss 2.4.4, how do I > correctly return > > > > > application level errors from my entity bean's > ejbStore method? Do > I > > > > throw > > > > > my own exception? Does this exception extend RemoteException, > > > Exception? > > > > > Since ejbStore actually overrides its ancestor's > method, how do I > > > declare > > > > > that my own exception will be thrown? If I don't > declare it as > being > > > > > thrown, I get a compile time error. > > > > > > > > > > Thanks for any clarity on this issue, > > > > > > > > > > Bill Pfeiffer > > > > > ----- Original Message ----- > > > > > From: "Olaf Strozyk" <[EMAIL PROTECTED]> > > > > > To: "danch" <[EMAIL PROTECTED]> > > > > > Cc: <[EMAIL PROTECTED]> > > > > > Sent: Monday, January 14, 2002 7:28 PM > > > > > Subject: Re: [JBoss-user] Passing Business Exception to Client > > > > > > > > > > > > > > > > danch wrote: > > > > > > > EJBException is actually a runtime exception that > you use to > > > complain > > > > to > > > > > > > the container when something _really_ wacky > happens that you > want > > > to > > > > > > > call a system error. The EJB spec defines a > business exception > > > (AKA > > > > > > > Application Exception) as a different category of > exception, > with > > > > > > > different behavior. > > > > > > > > > > > > > > To throw a business exception, define separate > classes for them, > > > > > > > extending RemoteException, then replace your 'throws > > > EJBException' > > > > > > > declaration with your newly defined exception. > > > > > > > > > > > > Hi, > > > > > > > > > > > > sorry to interfere, but let me help out with a > "not". The above > has > > > to > > > > > > be "_not_ extending RemoteException". > > > > > > > > > > > > See the spec (Enterprise JavaBeans 2.0, Final > Release, 18.1.1): > > > > > > "An application exception class must be a subclass > (direct or > > > indirect) > > > > > > of java.lang.Exception. An application exception > class must not be > > > > > > defined as a subclass of the > java.lang.RuntimeException or of the > > > > > > java.rmi.RemoteException." > > > > > > > > > > > > -Olaf > > > > > > > > > > > > > the biggest difference in the container's > behavior (aside from > > > passing > > > > > > > the proper exception back to the client) is that > when you throw > > > an > > > > > > > EJBException, the container marks your transaction > Rollback-only, > > > > while > > > > > > > it _doesn't_ for application exceptions. If you want your > > > transaction > > > > > > > rolled back, you'll need to call setRollbackOnly > yourself (on > the > > > > > > > session context). > > > > > > > > > > > > > > -danch > > > > > > > > > > > > > > Bill Pfeiffer wrote: > > > > > > > > > > > > > > > I am having a problem with JBoss 2.4.4 and > Tomcat 4.0.1. When > > > I > > > > > > > > encounter a business logic problem (or sql > problem, etc) and > > > want > > > to > > > > > > > > send it back to the client, I create and throw an > EJBException. > > > The > > > > > > > > problem I am encounter is that I actually > recieve, on the > > > client > > > > > > > > (Tomcat) end, an UndeclaredThrowableException > which contains > no > > > info > > > > > on > > > > > > > > the original error. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Probably related is the fact that I get these > warnings when > > > > deploying > > > > > my > > > > > > > > beans: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------ > > > > > > > > > > > > > > > > [ERROR,ContainerFactory] > > > > > > > > Bean : EBSecurityUser > > > > > > > > Method : public abstract String getPassword() throws > > > > RemoteException, > > > > > > > > EJBExcepti > > > > > > > > on > > > > > > > > Section: 9.2.7 > > > > > > > > Warning: The exceptions thrown by methods in the remote > > > interface > > > > must > > > > > > > > be valid > > > > > > > > types for RMI/IIOP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [ERROR,ContainerFactory] > > > > > > > > Bean : SBWebSessMgr > > > > > > > > Method : public abstract SBWebSessMgr create() throws > > > > CreateException, > > > > > > > > EJBExcept > > > > > > > > ion, RemoteException > > > > > > > > Section: 6.10.6 > > > > > > > > Warning: The method return values in the home > interface must > be > > > of > > > > > valid > > > > > > > > types f > > > > > > > > or RMI/IIOP. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [ERROR,ContainerFactory] > > > > > > > > Bean : SBEspeedUtility > > > > > > > > Method : public abstract SBCaseLockHome > getSbCaseLockHome() > > > throws > > > > > > > > RemoteExcepti > > > > > > > > on > > > > > > > > Section: 6.10.5 > > > > > > > > Warning: The method return values in the remote > interface must > > > be > > > of > > > > > > > > valid types > > > > > > > > for RMI/IIOP. > > > > > > > > > > > > > > > > --------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It appears the I am not returning throwing > valid types for > > > RMI/IIOP. > > > > > > > > Any ideas what would cause this? What > constitutes a valid > > > RMI/IIOP > > > > > > > > type or what would cause my objects not be > considered valid > > > RMI/IIOP > > > > > types? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for any assistance, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bill Pfeiffer > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > JBoss-user mailing list > > > > > > > [EMAIL PROTECTED] > > > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > > > > _______________________________________________ > > > > > > JBoss-user mailing list > > > > > > [EMAIL PROTECTED] > > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > > > > > > > _______________________________________________ > > > > > JBoss-user mailing list > > > > > [EMAIL PROTECTED] > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > > > > _______________________________________________ > > > > JBoss-user mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > _______________________________________________ > > > JBoss-user mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > > _______________________________________________ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
