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

时间：2013-02-05 13:20:12

标签： java jpa entity openjpa

我正在尝试创建@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没有'throws FieldNullException'，那么它可能允许getter的用户对null对象执行操作：

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

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

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

写一次，让它提醒你;）

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

3 个答案:

答案 0 :(得分：2)

不，它不是非法的，并且一些JPA实现（例如DataNucleus JPA）不会调用getter（除非使用属性访问时，你不是），这些是针对开发人员的打电话。持久性规范也不是要对开发人员强加任何东西;没有＆＃34;权利＆＃34;使用语言和设计你的类的方法所以如果你想要有行为的模型类那么好，它们应该以相同的方式持久化

答案 1 :(得分：1)

首先要开始的是enhance your Entities at build time, or use the -javaagent！不要使用openjpa.RuntimeUnenhancedClasses，因为该功能存在大量已知错误。

答案 2 :(得分：0)

即使可以完成，但并不意味着 。在实体中抛出异常对我来说似乎是一种糟糕的编码气味。实体应不具有任何业务逻辑，因此异常处理在任何地方都是不合适的。

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

相关问题
最新问题