JPAでの例外処理の改善

Question

私のエンティティを永続化するときにEJB3/JPAを使用しましたが、DB関連の タスクをどのように管理できるのか満足しています。 私の懸念は例外処理です。エンティティを保存するときのサンプルコードは、常にこのフレーバになります。 ネットで読んでいるチュートリアルのほとんどは、例外処理に関係なくこの風味になっています。

@Stateless 
public class StudentFacade{ 
    @PersistenceContext(unitName = "MyDBPU") 
    private EntityManager em; 

    public void save(Student student) { 
     em.persist(student); 
    } 
} 

しかし、私はEJBアプリケーションで例外処理の最良の方法を知っていませんか？ 例外を処理する最善の方法は何ですか？

他の人がこの例外をどのように処理していますか？あなたのセッションファサードでtry catchブロック？

@Stateless 
public class StudentFacade{ 
    @PersistenceContext(unitName = "MyDBPU") 
    private EntityManager em; 

    public void save(Student student) { 
     try { 
      em.persist(student); 
     } catch(Exception e) { 
      //log it or do something 
     } 
    } 
} 

このメソッドに例外をスローさせますか？

public void save(Student student) throws Exception { 
    em.persist(student); 
} 

私はまだEJBを学んでいますので、私の理解が正しいかどうか知りません。 ありがとう

Answer 1

例外処理の考え方は、障害が発生した場合に単一のポイントでいくつかのロジックを実行しています。 トライキャッチでは、例外を処理する必要があるか、

アプリは、多くの層、すなわちアクション、ファサードを持っていると言う別の例外に例外を変換する必要があり、

委任例外を永続化し、最終的なポイントで使用されます この場合、Facadeでスローされた例外は、上記のアクションレイヤーにスローされます。 実際には、特定の例外が検出され、適切なエラーメッセージが表示されます。

//This is in Facade Layer 
public void save(Student student) throws AppException{ 
    //exceptions delegated to action layer 

    //call to Persist Layer 
} 

あなたが得るとのSQLExceptionのようなDBException持続性のApp例外 言って一般的な例外を変換します。この例外は、アクションやファサード層になどとして送信すべきではないので、我々は、特定の例外をキャッチして、 あなたがキャッチする行為層の新しい例外（アプリケーションのユーザー定義の例外）

//This is in Persist Layer 
public void save(Student student) throws AppException{ 
     //converting general exception to AppException and delegating to Facade Layer 

     try{ 
      em.persist(student);//call to DB. This is in Persist Layer 
     }catch(Exception e){ 
      throw new AppException("DB exception", e) 
     } 
    } 

を投げますあなたの例外アクションで、その後はそこ

を例外を処理

//This is in Action layer 
    public void callSave(Student student){ 
      try{ 
       //call Facade layer 
      }catch(AppException e){ 
       //Log error and handle 
      } 
    } 

Answer 2

例外をem.persistance（...）からスローするには、try/catchブロックでそのステートメントを囲まないでください（そのブロック内のすべての例外をキャッチする）。

この問題にアプローチする方法は、レガシーコードが既に存在するかどうかにかかわらず、アプリケーションによって異なります。レガシーコードがある場合は、一貫性を維持するために同じアプローチを使用することをお勧めします（速度最適化でもない場合もあります）。

それ以外の場合は、「大雑把なルール」の例外に従うことをお勧めします。まず行動をとるために必要なすべての情報を持っている最初の場所で扱う必要があります。 （あなたがそれらを投げ捨てるならば、あなたが投げることができる最も特殊な例外の型を投げてください（一般的な例外ではありません））。 JPAを使用するときの例外の処理は、一般的にJavaの例外を処理する方法と変わりありません。

これは、「宗教的な会話」を開始することなく、例外に関する十分な情報だったと思います。

Answer 3

あなたの組み合わせは、JPAとEJBの場合は、すべてのJPAの例外が実行時例外です。

EJBの取り扱い

アプリケーション例外は、基本的に、我々は、ビジネスの検証とビジネスルールを使用している例外をチェック例外1）アプリケーション例外2）システム例外の2種類。

システム例外はランタイム例外です。したがって、実行時の問題が発生した場合、ejbコンテナは干渉し、実行時例外をリモート例外として変換します。 EXのために

：DAO層における

public void store(Cargo cargo) { 
    entityManager.persist(cargo); 
} 

すべてのJPAの例外は実行時例外です。 EJBサービス層における

：任意のランタイム例外起こっ、EJBコンテナが干渉し、リモート例外に変換する場合は、EJB層で

public TrackingId bookNewCargo(UnLocode originUnLocode, 
     UnLocode destinationUnLocode, 
     Date arrivalDeadline) { 

    Cargo cargo = new Cargo(trackingId, routeSpecification); 
    cargoRepository.store(cargo); 
    return cargo.getTrackingId(); 
} 

。界面層で

：そう

、このJPAのように - > EJB - >インタフェース