Non-inline code such as this (this process occurs as part of transaction handling) is difficult to always wrap. In general this requires delegation to handle properly (org.hibernate.proxy.EntityNotFoundDelegate e.g.)
Another idea (that requires a whole separate thread) would be to consolidate native Hibernate and JPA codebases as we move into 5.0. That would include exception hierarchies as much as possible. On 11/09/2012 07:22 PM, Christian Bauer wrote: > I've noticed some cases where a native Hibernate exception is not wrapped in > a javax.persistence.OptimisticLockException. > > EntityVerifyVersionProcess.java throws an > org.hibernate.OptimisticLockException that is passed on directly to JPA users. > > EntityIncrementVersionProcess.java passes through the > org.hibernate.StaleObjectStateException from > AbstractEntityPersister#forceVersionIncrement() without wrapping. If wrapping > in JPA isn't possible, at least this one should be wrapped in an > o.h.OptimisticLockException for consistency sake. > > Are JPA users expected to catch all three exceptions when using versioning? > Is OptimisticEntityLockException useful? > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
