Exceptions from callbacks

[Conrad Leonard]

I'm using some entity listener classes with my Empire-annotated beans to do validation & some other things, and in a couple of cases I throw exceptions from the listener methods e.g. when validation fails. A toy example:

public class RemoveProhibitor {

    @PreRemove

    public void prohibit(Object o) {

        throw new PersistenceException( o.getClass().getName() + " instances may not be removed");

    }

}

I would expect that this would in fact prevent the removal of o, but it doesn't, apparently because in EntityManagerImpl all exceptions thrown by the listener method are caught, logged, and not re-thrown:

                        try {

                                for (Method aListenerMethod : aListenerMethods) {

                                        aListenerMethod.invoke(aListener, theObj);

                                }

                        }

                        catch (Exception e) {

                                LOGGER.error("There was an error during lifecycle notification for annotation: " +

                                                         theLifecycleAnnotation + " on object: " + theObj + ".", e.getCause());

                        }

Same deal for pre-persist & pre-update methods, I would expect that exceptions thrown in the listener method would cause the persist & merge operations to fail - although, I am not an expert in JPA so perhaps my expectation is not correct.

What do you think about adding the following second line to the catch block [after the LOGGER.error(...)] :

                                throw new PersistenceException(e.getCause());

and leave the actual handling to something higher up the stack?

[Michael Grove]

Yeah, I think this would be a good change.  I'm not entirely sure what the JPA spec prescribes in this case, but it seems entirely reasonable that the exceptions would bubble up to the application layer so that the user can decide what to do about the situation.

I've created #110 [1] for this.

Thanks.

Mike

[1] https://github.com/mhgrove/Empire/issues/110 

 

--
You received this message because you are subscribed to the Google Groups "Empire" group.
To unsubscribe from this group and stop receiving emails from it, send an email to empire-rdf+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Conrad Leonard]

I took a look just now and couldn't find anything explicit in JPA 1 (EJB 3.0) spec about this but in 2.0 spec on the section 3.5 Entity Listeners and Callback Methods there is this:

3.5.6 Exceptions
Lifecycle callback methods may throw runtime exceptions. A runtime exception thrown by a callback
method that executes within a transaction causes that transaction to be marked for rollback. No further
lifecycle callback methods will be invoked after a runtime exception is thrown.

There is similar text in 3.5.7 of 2.1 spec. 

Which I guess confirms this expectation is correct (at least for JPA 2+)