The user application needs to scan through the raised exception and its nested exception(s) recursively to reach at a target exception (e.g. EntityExistsException).
One of the causes of EntityExistsException is rooted in some sort of "Duplicate Key Exception" raised by JDBC driver. Now SQL error code of a specific SQLException is supposed to be uniform across different databases but, in reality, it hardly is. So OpenJPA uses a resource file [1] to map SQL error codes to specific kind of exceptions recognized by the object management kernel e.g. EntityExistsException or ReferentialIntegrityException. Populating this resource file with appropriate SQL error code for the target database will help to narrow down the cause to EntityExistsException and if you flush() before commit, you are likely to catch EntityExistsException directly. [1] openjpa-jdbc\src\main\resources\org\apache\openjpa\jdbc\sql\sql-error-state-codes.xml ruslan wrote: > > Guys, could you please suggest me how you handle attempt to add duplicate > into table in your application? > > What's the best way of finding exception which I can handle when thrown > exception consist of bunch of other nested exceptions? Here is example: > http://pastebin.com/m3505bcbc As you can see topmost is > 'RollbackException', but I'm interested in first 'EntityExistsException' > which is real cause. Currently I catch RollbackException, then create List > of all nested exceptions and looking for ones which I know about such as > EntityExistsException. But this approach doesn't seem good to me. > > Thanks! > -- View this message in context: http://n2.nabble.com/Handling-nesting-exceptions-%28EntityExistsException%29-tp1567049p1573410.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
