5

OperationWrapper という名前のログ操作を担当するラッパーがあります。その構造は単純で、次のとおりです。

public void runOperation(Operation o) throws Exception{ 
     logOperationStarted();
     o.execute();
     logOperationFinished();
}

「o」操作は例外をスローする可能性があるため、logOperationFinished()メソッドが常に呼び出されるとは限らず、ロギングが正しく動作しません。

また、runOperation()メソッドを呼び出すさまざまなコンポーネントがこれらの例外を処理します。

常に実行されるようにしたかったのでlogOperationFinished()、次の構造を実装しました。

public void runOperation(Operation o) throws Exception{ 
     logOperationStarted();
     try{
       o.execute();
     }
     catch(Exception e){
       throw e; 
     }
     finally{
       logOperationFinished();
     }
}

logOperationFinished()常に実行されるようになりましたが、IntelliJ から警告が表示されます。

キャッチされた例外はすぐに再スローされます キャッチされた例外がアクションを実行せずにすぐに再スローされるすべてのcatch
ブロックを 報告します。このような catchブロックは不要であるか、エラー処理が不足しています。

私には、この警告を発行するときに、IntelliJ が finally ブロックを考慮していないようです。

私は何か間違ったことをしていますか、それともこれを達成するためのより良い方法はありますか?

ありがとう。

4

3 に答える 3

8

はい、キャッチは必要ありません

public void runOperation(Operation o) throws Exception{ 
     logOperationStarted();
     try{
       o.execute();
     }
     finally{
       logOperationFinished();
     }
}
于 2015-04-07T05:09:08.743 に答える
2

JLS 14.20.2の try-finally ブロックを使用します。try-finally の実行

try ブロックの実行が R 以外の理由で突然終了した場合、finally ブロックが実行され、次の選択肢があります。

  1. finally ブロックが正常に完了すると、try ステートメントは R の理由で突然完了します。

  2. finally ブロックが理由 S で突然終了した場合、try ステートメントは理由 S で突然終了します (理由 R は破棄されます)。

public void runOperation(Operation o) throws Exception{ 
     logOperationStarted();
     try{
        o.execute();
     }finally{
       logOperationFinished();
     }
}

それでも try-catch-finally を使用したい場合は、IntelliJ からの警告を無視するか、catch ブロックから新しい例外をスローすることができます。

throw new ExceptionYouWantToThrow(e);
于 2015-04-07T05:16:16.510 に答える
0

例外は回復可能であることを意図していますか? そうでない場合は、例外を再スローするのではなく、エラーをスローする方が適切な場合があります。

ただし、怖いウォンバットの答えは、おそらくあなたが求めているものです.

throw new Error(e);

例外とエラー

于 2015-04-07T05:15:40.623 に答える