Is a method in a JPA entity allowed to throw an Exception?

问题

I have a problem with an @Entity I am trying to create. The problem arises when trying to test the class in Eclipse using an OpenJPA implementation (I have not tried others so not sure if it might work with them).

My test case is simple enough in that it creates an EntityManagerFactory (which automatically finds the persistence.xml on my classpath) and then it tries to create an EntityManager from the factory. This is when I get hit with a very ambiguous 'PersistenceException: null' error.

The Entity with the problem is the following LogError class. I have stripped it down to the bare minimum and it still throws an error.

@Entity
@Table(name = "T_LOG_ERROR")
public class LogError {

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long ID;

private String ERROR;

protected LogError() {}

public String getErrorName() throws FieldNullException {
    if (this.ERROR == null)
        throw new FieldNullException("error was null", null);
    return this.ERROR;
}

public setError(SystemError error) {
    this.ERROR = error.getClass().getCanonicalName();
}   

}

I have discovered that the problem seems to lie with throwing an exception within the getErrorName() method. You see, if I was to comment out the first two lines of the method like so:

public String getErrorName() throws FieldNullException {
    //if (this.ERROR == null)
    //  throw new FieldNullException("caughtException was null", null);
    return this.ERROR;
}

then the error disappears. Just to clarify, the FieldNullException is my own custom made exception, however it does not make a difference as I have tried with standard java exceptions such as NullPointerException and the error is the same.

So my question is, is it illegal to throw exceptions with methods of an Entity class?

And also why do I get an error?

Here is my tester method:

@Test
public final void test() {
    emf = Persistence.createEntityManagerFactory("testPersistenceUnit");
    emf.createEntityManager(); // problem arises here!
}

I have attached the stack trace below:

<openjpa-2.2.0-r422266:1244990 fatal general error> org.apache.openjpa.persistence.PersistenceException: null
at org.apache.openjpa.enhance.ClassRedefiner.redefineClasses(ClassRedefiner.java:96)
at org.apache.openjpa.enhance.ManagedClassSubclasser.prepareUnenhancedClasses(ManagedClassSubclasser.java:176)
at org.apache.openjpa.kernel.AbstractBrokerFactory.loadPersistentTypes(AbstractBrokerFactory.java:314)
at org.apache.openjpa.kernel.AbstractBrokerFactory.initializeBroker(AbstractBrokerFactory.java:238)
at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:212)
at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:156)
at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:227)
at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:154)
at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:60)
at 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.openjpa.enhance.ClassRedefiner.redefineClasses(ClassRedefiner.java:85)
... 34 more
Caused by: java.lang.VerifyError
at sun.instrument.InstrumentationImpl.retransformClasses0(Native Method)
at sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:144)
... 39 more

Why I want to throw the exception anyway

For me, throwing a FieldNullException on each getter method that represents a column that NULL is allowed, forces the user of these getter methods to take appropriate action when needing the values of these getters.

So for example:

// At some point this object is created:
LogError logError = new LogError();
logError.setError(new SystemError());

// Some point later, someone wants to retreive the error name from this object 
// and pull only the first 10 letters for display
try {
    return logError.getErrorName().substring(0,10); // Safely perform substring
} catch (FieldNullExcepion) {
    return "";
}

If my getter did not have a 'throws FieldNullException' then it potentially allows a user of the getter to perform an action on a null object:

// If getErrorName() returns null, then this will throw NullPointerException!
return logError.getErrorName().substring(0,10) 

To avoid this the user can obviously check if the returned value from the getter is null before performing anything else and there is nothing wrong with that. The benefit of my way, is simply to say 'hey, this field may contain null so take appropriate action'.

And an Entity can have many fields, so attaching 'throws NullFieldException' on the getters that allow null, will conveniently signal to the caller which exact fields may be null and thus take alternative action on them. Thus not having to try and remember which may be null or pulling up your entity to check for your @NotNull annotations etc.

Write once and let it remind you ;)

I do not use these methods for validation and I don't see how it is business logic. It is completely to do with the characteristic of the underlying database field.

回答1:

A first place to start would be to enhance your Entities at build time, or use the -javaagent! Don't use openjpa.RuntimeUnenhancedClasses as there are lots of known bugs with that feature.

回答2:

No its not illegal, and some JPA implementations (e.g DataNucleus JPA) don't go about calling getters (except when using property access, which you aren't), those are for the developer to call. It also isn't for persistence specifications to impose anything on a developer; there is no "right" way to use a language and design your classes so if you want to have model classes with behaviour then fine, and they should be persistable in the same way

回答3:

Even though it can be done, it doesn't mean you should. Throwing exceptions in an entity seems like a bad coding smell to me. Entities should not have any business logic, so exception handling in there would be out of place, anyway.

Java EE design patterns encourage a procedural way of thinking, applying OO concepts at the entity level is OK for modeling data (inheritance, polymorphism, etc.) but not behavior - that is to say, validation logic, business logic etc. should reside outside entities and exist only in business classes. The only business logic that makes sense to put in an entity, would be the named queries that apply to it.

来源：https://stackoverflow.com/questions/14708516/is-a-method-in-a-jpa-entity-allowed-to-throw-an-exception