Yes, I think that logic is not correct. A bigger concern I have there tbh is HEM; there is some very fragile (at best) code that tries to "decode" the exceptions thrown by the native APIs. That stuff could very easily break.
On Tue, Apr 28, 2015 at 4:32 PM, Gunnar Morling <gun...@hibernate.org> wrote: > TransactionImpl#commit(); The before-completion code is now invoked > through transactionDriverControl.commit(); whereas previously this > happened out of a try/catch block. > > 2015-04-28 23:26 GMT+02:00 Steve Ebersole <st...@hibernate.org>: > >> Where does that wrapping happen? >> >> On Tue, Apr 28, 2015 at 3:53 PM, Gunnar Morling <gun...@hibernate.org> >> wrote: >> >>> Hi, >>> >>> while working on making OGM work with ORM 5, I noticed a slightly >>> different >>> behaviour wrt. to exceptions occurring during flushes. >>> >>> Previously, such exceptions would bubble up as is, whereas now the >>> beforeTransactionCompletion() logic is called in a try/catch block, >>> wrapping any exceptions in a TransactionException. It's no big deal for >>> me >>> (I just need to adapt some tests in our suite which expect specific >>> exception types), but then I was wondering whether that change poses a >>> migration issue for existing client code, e.g. >>> expecting/handling StaleObjectStateException which would need to be >>> adapted >>> accordingly? >>> >>> Anyone thinking it's a problem? >>> >>> Thanks, >>> >>> --Gunnar >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
