例外処理内での例外処理

Question

例外処理のベストプラクティスは内の例外処理ですか？

キャッチ内でカスタムオブジェクトを使用し、システムのほとんどのアプリケーションサーバー層でブロックする既存のC＃（Framework 4.0）システムで作業しています。私は過度に偏執的なことかもしれないが、私はこれらに発生する可能性のある未処理の例外について自分自身を非常に心配見つける

public void DoSomeStuff(string sGUID) 
    { 
     try 
     { 
      // Foo 
     } 
     catch (Exception oEx) 
     { 
      oExceptions.Add(oEx); 

      if (oDBConn.NumberOfActiveTrans > 0) 
      { 
       oDBConn.Rollback(); 
      } 
     } 
     finally 
     { 
      oDBConn.DeleteLocksByGUID(sGUID); 
     } 
    } 

：

は、このコードベースのメソッドの次切り取らバージョンを考えてみましょう。

このように、次のような更新されたバージョンが受け入れ可能なプラクティスか、同じことを達成するためのよりよい方法がありますか？

public void DoSomeStuff(string sGUID) 
    { 
     try 
     { 
      // Foo 
     } 
     catch (Exception oEx) 
     { 
      oExceptions.Add(oEx); 

      try 
      { 
       if (oDBConn.NumberOfActiveTrans > 0) 
       { 
        oDBConn.Rollback(); 
       } 
      } 
      catch (Exception oEEx) 
      { 
       oExceptions.Add(oEEx); 
      } 
     } 
     finally 
     { 
      try 
      { 
       oDBConn.DeleteLocksByGUID(sGUID); 
      } 
      catch (Exception oFEx) 
      { 
       oExceptions.Add(oFEx); 
      } 
     } 
    } 

Answer 1

私は個人的に、それは無限連鎖することができ、finallyでtry catchブロックを追加しないでしょう。通常、あなたはfinallyに複雑なものを入れてはいけません。いずれにしても、予期せぬ例外は呼び出し元に捕らえられるべきです。

編集：コードに少し近いところを見て、私はなぜfinallyブロックのコードがtryブロック内にあるべきでないのか分かりません。

Answer 2

私は過度の編集的症例かもしれませんが、私は自分自身が非常に心配してこれらの問題が発生する可能性があります 可能性があります。

パニックにはなりません。 db層にエラーがある場合は、そこにキャッチしてください。

Answer 3

元のコードで最も危険なのは、エラーが発生した場合は、トランザクションのロールバックに失敗したとです。トランザクションをロールバックしたときのエラーのみが再現されます。最初の例外がトランザクションをロールバックしなければならなかった原因はわかりません。それはあなたが最も気にするものです。

あなたが妄想になりたい場合は、トランザクションロールバックの失敗を記録します。しかし重要なことは、その点まであなたを得た以前の例外です。これは、呼び出し元の期待に応じてログに記録されるか、再スローされる必要があります。