java - JPA 实体中的方法是否允许抛出异常？

Question

我尝试创建的 @Entity 遇到问题。当尝试使用 OpenJPA 实现在 Eclipse 中测试该类时，就会出现问题(我没有尝试过其他实现，因此不确定它是否适用于它们)。

我的测试用例非常简单，因为它创建一个 EntityManagerFactory(它自动在我的类路径上查找 persistence.xml)，然后尝试从工厂创建一个 EntityManager。这时我遇到了一个非常模糊的“PersistenceException:null”错误。

有问题的实体是以下 LogError 类。我已将其精简到最低限度，但它仍然会抛出错误。

@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();
}   

}

我发现问题似乎在于在 getErrorName() 方法中引发异常。你看，如果我像这样注释掉该方法的前两行:

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

然后错误就消失了。只是为了澄清一下，FieldNullException 是我自己定制的异常，但是它没有什么区别，因为我尝试过标准 java 异常(例如 NullPointerException)并且错误是相同的。

所以我的问题是，使用实体类的方法引发异常是否违法？

为什么我会收到错误？

这是我的测试方法:

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

我已附上下面的堆栈跟踪:

<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

为什么我还是想抛出异常

对我来说，在每个代表允许 NULL 的列的 getter 方法上抛出 FieldNullException，会强制这些 getter 方法的用户在需要这些 getter 的值时采取适当的操作。

例如:

// 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 "";
}

如果我的 getter 没有“抛出 FieldNullException”，那么它可能允许 getter 的用户对 null 对象执行操作:

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

为了避免这种情况，用户可以在执行任何其他操作之前检查 getter 返回的值是否为 null，这没有任何问题。我的方法的好处是简单地说“嘿，该字段可能包含 null，所以采取适当的操作”。

实体可以有许多字段，因此在允许 null 的 getter 上附加“抛出 NullFieldException”，将方便向调用者发出信号，表明哪些字段可能为 null，从而对它们采取替代操作。因此不必尝试记住哪些可能为 null 或拉出您的实体来检查您的 @NotNull 注释等。

写一次，让它提醒你；)

我不使用这些方法进行验证，并且我不明白它是如何实现业务逻辑的。这完全和底层数据库领域的特性有关。

Answer 1

不，这并不非法，并且某些 JPA 实现(例如 DataNucleus JPA )不会调用 getter(除非使用属性访问，但您不是)，这些是供开发人员调用的。持久性规范也不会强加给开发人员任何东西；没有“正确”的方法来使用语言和设计类，因此如果您想要具有行为的模型类那就很好，并且它们应该以相同的方式持久化