It depends. - If you're hand coding everything yourself, I would suggest some kind of observer-listener approach where you listen for specific the exceptions & take the necessary action. If you're using a framework like JBoss Seam, for example, this can be done declaratively (application wide). I'm sure Spring[1] and other frameworks have some kind of implementation of that design pattern.
- The other (less elegant) option is to try/catch all 8 exceptions in the JPA (EntityExists, EntityNotFound, OptimisticLock, NoResult, TransactionRequired, etc. etc.) in the webMethod of your web-service (or the ExceptionInterceptor in as it may be) and tell the client what happened. Obviously this assumes that the persistence-manager didn't change/wrap the exception. > the only way to make this that comes to my mind is to catch the exception > and look for some keyword exception in the stack trace and then find out > what is the cause The bad news is OpenJPA has its own exceptions [e.g. ObjectNotFoundException instead of javax.persistence.EntityNotFoundException]; the good news is you can just catch their parent StoreException and call getType() [1] <http://docs.huihoo.com/jboss/seam/2.0.0.GA/reference/en/html/events.html#d0e4460> http://www.theserverside.com/tt/articles/article.tss?l=SpringLoadedObserverPattern Judes On Sat, Nov 29, 2008 at 10:17 AM, is_maximum <[EMAIL PROTECTED]> wrote: > > Actually this question is related to EJB 3 but I since I am using OpenJPA I > thought it was better to put my question here. > > when you are using merge() or persist() methods of EntityManager, these > methods may throw SQLException wrapped in PersistenceException and finally > at the end of my business method I will catch an EJBRollbackException or > EJBRuntimeException, I don't want to catch it to recover from the situation > but want to return back an appropriate message. for example, notify the > user > that this record has at least one child record so you can't remove it or > another record with this information is already exists and etc. > because we are using webservices and our clients application are developed > in .NET platform we have a ExceptionInterceptor to catch all the exception > and send back an appropriate error code to notify the user. > > the only way to make this that comes to my mind is to catch the exception > and look for some keyword exception in the stack trace and then find out > what is the cause > > I am wondered why they didn't take this into account while they have > provided EntityExistException but not the other states. > > > Wes Wannemacher wrote: > > > > I'm not sure if this is a question specific to openjpa, but it doesn't > > seem like it, so I will answer as though it is not. In general, whenever > > working at a level that would encounter a Sql Exception, I catch them > > and wrap them in an application specific Exception that is unchecked. I > > don't think I've ever had a SQLException that application code can > > recover. Or, at least, never have I come across a situation where the > > effort to recover from the exception is worthwhile. > > > > Lately, I have been using Spring quite a bit... Within Spring's database > > APIs, SQLExceptions are caught and wrapped in much more useful > > exceptions that are unchecked. > > > > -Wes > > > > -- > View this message in context: > http://n2.nabble.com/how-do-you-manage-db-exceptions--tp1591722p1592956.html > Sent from the OpenJPA Users mailing list archive at Nabble.com. > >
