2

我尝试创建的@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，并且错误是相同的。

所以我的问题是，使用 Entity 类的方法抛出异常是否违法？

还有为什么我会出错？

这是我的测试方法：

@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 的用户对空对象执行操作：

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

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

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

写一次，让它提醒你；）

我不使用这些方法进行验证，也看不出它是如何实现业务逻辑的。这完全与底层数据库字段的特性有关。

4

3 回答 3

2

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

于 2013-02-05T13:43:11.603 回答
1

首先要开始在构建时增强您的实体，或使用 -javaagent！不要使用openjpa.RuntimeUnenhancedClasses，因为该功能有很多已知的错误。

于 2013-02-05T21:25:01.963 回答
0

即使可以做到，也不代表应该做。在实体中抛出异常对我来说似乎是一种不好的编码气味。实体不应该有任何业务逻辑，所以那里的异常处理无论如何都是不合适的。

Java EE 设计模式鼓励一种程序化的思维方式，在实体级别应用 OO 概念可以用于建模数据（继承、多态等），但不能用于建模行为 - 也就是说，验证逻辑、业务逻辑等应该驻留在外部实体并且仅存在于业务类中。放入实体中唯一有意义的业务逻辑是应用于它的命名查询。

于 2013-02-05T13:38:34.307 回答