是否允许JPA实体中的方法抛出exception？
我有一个@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（）方法中抛出exception。 你看，如果我要注释掉方法的前两行，如下：
public String getErrorName() throws FieldNullException { //if (this.ERROR == null) // throw new FieldNullException("caughtException was null", null); return this.ERROR; }
然后错误就消失了。 只是为了澄清一下，FieldNullException是我自己的自定义exception，但它没有区别，因为我尝试使用标准的Javaexception，如NullPointerException，并且错误是相同的。
所以我的问题是，使用Entity类的方法抛出exception是非法的吗？
还有为什么我会收到错误？
这是我的测试方法：
@Test public final void test() { emf = Persistence.createEntityManagerFactory("testPersistenceUnit"); emf.createEntityManager(); // problem arises here! }
我在下面附上了堆栈跟踪：
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
无论如何我为什么要抛出exception
对我来说，在每个表示允许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的信号，从而对它们采取替代操作。 因此，不必尝试记住哪些可能为null或拉起您的实体以检查您的@NotNull注释等。
写一次，让它提醒你 ;）
我不使用这些方法进行validation，我不知道它是如何进行业务逻辑的。 它完全与底层数据库字段的特性有关。
首先要做的是在构建时增强您的实体，或者使用-javaagent ！ 不要使用openjpa.RuntimeUnenhancedClasses因为有很多已知的错误与该function。
不，它不是非法的，并且一些JPA实现（例如DataNucleus JPA ）不会去调用getter（除非使用属性访问时，你不是），这些是供开发人员调用的。 持久性规范也不适用于开发人员; 没有“正确”的方式来使用语言和设计你的类，所以如果你想让模型类的行为那么好，它们应该以相同的方式保持不变
尽管可以做到，但这并不意味着你应该这样做。 在实体中抛出exception对我来说似乎是一种糟糕的编码气味。 实体不应该有任何业务逻辑，因此无论如何，exception处理都是不合适的。
Java EE设计模式鼓励采用程序化的思维方式，在实体级应用OO概念可以建模数据（inheritance，多态等），但行为不行 – 也就是说，validation逻辑，业务逻辑等应该驻留在外部实体，仅存在于业务类中。 放入实体的唯一业务逻辑是适用于它的命名查询。