3

その状況では、ErrorCode または Exception のどちらが優れていますか?

これら 2 つのエラー処理手法を見たことがあります。各手法の短所と利点がわかりません。

public void doOperation(Data data) throws MyException {
    try {
        // do DB operation
    } catch (SQLException e) {
        /* It can be ChildRecordFoundException, ParentRecordNotFoundException
         * NullValueFoundException, DuplicateException, etc..
         */
        throw translateException(e);
    }
}

また

public void doOperation(Data data) throws MyException {
    try {
        // do DB operation
    } catch (SQLException e) {
        /* It can be "CHILD_RECORD_FOUND, "PARENT_RECORD_NOT_FOUND"
         * "NULL_VALUE_FOUND", "DUPLICATE_VALUE_FOUND", etc..
         */
        String errorCode = getErrorCode(e);
        MyException exc = new MyException();
        exc.setErrorCode(errorCode);
        throw exc;
    }
}

2 番目の方法では、エラー コードはフォーム構成ファイルを取得します。Error Codeに基づいて追加できSQL Vender Codeます。

SQL_ERROR_CODE.properties

#MySQL Database
1062=DUPLICATE_KEY_FOUND
1216=CHILD_RECORD_FOUND
1217=PARENT_RECORD_NOT_FOUND
1048=NULL_VALUE_FOUND
1205=RECORD_HAS_BEEN_LOCKED

メソッド 1 の呼び出し側クライアント

    try {

    } catch(MyException e) {
        if(e instanceof ChildRecordFoundException) {
            showMessage(...);
        } else if(e instanceof ParentRecordNotFoundException) {
            showMessage(...);
        } else if(e instanceof NullValueFoundException) {
            showMessage(...);
        } else if(e instanceof DuplicateException) {
            showMessage(...);
        }
    }

メソッド 2 の呼び出し元クライアント

    try {

    } catch(MyException e) {
        if(e.getErrorCode().equals("CHILD_RECORD_FOUND")) {
            showMessage(...);
        } else if(e.getErrorCode().equals("PARENT_RECORD_NOT_FOUND") {
            showMessage(...);
        } else if(e.getErrorCode().equals("NULL_VALUE_FOUND") {
            showMessage(...);
        } else if(e.getErrorCode().equals("DUPLICATE_VALUE_FOUND") {
            showMessage(...);
        }
    }
4

5 に答える 5

6

Spring の使用をお勧めしJDBCTemplateます。ほとんどの既存のデータベースの例外を、特定の未チェックの例外に変換しますDataIntegrityViolationException。メッセージには元の SQL エラーも含まれます。

于 2012-09-19T09:58:24.980 に答える
2

どちらのアプローチも同じことを行うため、奇妙な質問です。チェックされた SqlException を、チェックされていないように見える別の例外に変換します。したがって、これを単一のメソッドに移動するため、最初のものの方が優れています。

どちらもいくつかの質問が残されています。

  • この変換を実行できるインフラストラクチャはありませんか (Spring Template は別の回答で言及されています)。

  • チェックされた例外が本当に必要ですか。

  • 例外の実際の処理を行っているのは誰ですか? 必要なすべての情報を取得していますか? 通常、MyException 内で失敗したトランザクションに関する追加情報が期待されます。たとえば、次のようなものです。(例: ビジネス オブジェクトの更新); どんなオブジェクトに？(例: 人); 私たち/ユーザーはどのようにしてオブジェクトを識別できますか (例: person.id + person.lastname + person.firstname)。あなたやあなたのユーザーに「おっと、何かがおかしい」以上のことを伝えるログ/エラーメッセージを生成したい場合は、この種の情報が必要になります。

  • MyException が変更可能なのはなぜですか (少なくとも 2 番目の例では)

于 2012-09-19T10:14:40.043 に答える
1

どちらよりも優れた設計は、拡張してカスタム例外をチェックしないようにすることRuntimeExceptionです。

あなたの例外で最初のものをラップしたいので、このようにコーディングする方が良いでしょう:

MyException exception = new MyException(e); // wrap it.

それを行う場合、2番目のものが優先されます。情報が多いほどよい。

于 2012-09-19T09:56:15.940 に答える
1

IMHO、それはあなたのコードがSQLとどれだけ緊密に結合されているかによって異なります。

メソッドが常にSQLException(*1) SQL と結合される場合、 (リソースのクリーンアップ / クローズ後) を宣言して再スローします。SQL を認識する上位のメソッドは、適切と思われる方法でそれを処理します (すべての詳細が必要な場合もあれば、そうでない場合もあります)。

将来、SQL を使用しない別の方法に変更できる場合は、2 番目のオプションを選択します。

(1): この仮定で非常に悲観的になる: 「私たちは変わらないと思う」は、「おそらく私たちは変わりたいと思うだろう」と解釈されるべきです。「変更するつもりはない」とは、「とにかく他の多くのメソッドを壊さずに変更することはできない」という意味です。

于 2012-09-19T10:04:06.227 に答える
0

1 つの違いは、例外を処理する方法ですcatch。最初のケースではcatch、例外だけでエラーが何であるかがわかります。2 番目のケースではcatch、例外が発生し、コードをチェックしてエラーの内容を確認する必要があります。

于 2012-09-19T10:15:31.737 に答える