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() メソッド内で例外をスローすることに問題があるように思われることを発見しました。メソッドの最初の 2 行を次のようにコメントアウトすると、次のようになります。

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

その後、エラーは消えます。明確にするために、FieldNullException は私自身のカスタム例外ですが、NullPointerException などの標準の Java 例外で試したところ、エラーは同じであるため、違いはありません。

私の質問は、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 が許可されている列を表す各ゲッター メソッドで FieldNullException をスローすると、これらのゲッター メソッドのユーザーは、これらのゲッターの値が必要なときに適切なアクションを実行する必要があります。

たとえば、次のようになります。

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

ゲッターに 'throws FieldNullException' がない場合、ゲッターのユーザーが 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 アノテーションなどを確認したりする必要はありません。

一度書いて思い出させてください;）

これらのメソッドを検証に使用していないため、それがビジネス ロジックであることがわかりません。これは、基礎となるデータベース フィールドの特性に完全に関係しています。

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 に答える