C＃で例外をキャッチして再スローする理由

記事C＃-シリアル化可能なDTO上のデータ転送オブジェクトを見ています。

記事には次のコードが含まれています。

public static string SerializeDTO(DTO dto) {
    try {
        XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
        StringWriter sWriter = new StringWriter();
        xmlSer.Serialize(sWriter, dto);
        return sWriter.ToString();
    }
    catch(Exception ex) {
        throw ex;
    }
}

記事の残りの部分は正気で妥当なように見えますが（noobにとって）、そのtry-catch-throwはWtfExceptionをスローします... これは、例外をまったく処理しないこととまったく同じではありませんか？

エルゴ：

public static string SerializeDTO(DTO dto) {
    XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
    StringWriter sWriter = new StringWriter();
    xmlSer.Serialize(sWriter, dto);
    return sWriter.ToString();
}

または、C＃でのエラー処理に関する基本的な何かが欠けていますか？Java（チェック済みの例外を除く）とほとんど同じですよね。...つまり、どちらもC ++を洗練しました。

スタックオーバーフローの質問パラメーターなしのキャッチを再スローすることと何もしないことの違いは何ですか？try-catch-throwは何もしないという私の主張をサポートしているようです。

編集：

将来このスレッドを見つけた人のために要約すると...

しない

try {
    // Do stuff that might throw an exception
}
catch (Exception e) {
    throw e; // This destroys the strack trace information!
}

スタックトレース情報は、問題の根本的な原因を特定する上で非常に重要です。

行う

try {
    // Do stuff that might throw an exception
}
catch (SqlException e) {
    // Log it
    if (e.ErrorCode != NO_ROW_ERROR) { // filter out NoDataFound.
        // Do special cleanup, like maybe closing the "dirty" database connection.
        throw; // This preserves the stack trace
    }
}
catch (IOException e) {
    // Log it
    throw;
}
catch (Exception e) {
    // Log it
    throw new DAOException("Excrement occurred", e); // wrapped & chained exceptions (just like java).
}
finally {
    // Normal clean goes here (like closing open files).
}

（Javaのように）より具体的でない例外の前に、より具体的な例外をキャッチします。

参照：

• MSDN-例外処理
• MSDN-try-catch（C＃リファレンス）

最初; 記事のコードが行う方法は悪です。throw ex例外のコールスタックを、このthrowステートメントがあるポイントにリセットします。例外が実際に作成された場所に関する情報を失う。

次に、そのようにキャッチして再スローしただけの場合、付加価値はありません。上記のコード例throw exは、try-catchがなくても同じように（または、ビットを考えるとさらに優れています）です。

ただし、例外をキャッチして再スローする必要がある場合があります。ロギングはそれらの1つである可能性があります。

try 
{
    // code that may throw exceptions    
}
catch(Exception ex) 
{
    // add error logging here
    throw;
}

これを行わないでください。

try 
{
...
}
catch(Exception ex)
{
   throw ex;
}

スタックトレース情報が失われます...

どちらか、

try { ... }
catch { throw; }

または

try { ... }
catch (Exception ex)
{
    throw new Exception("My Custom Error Message", ex);
}

再スローしたくなる理由の1つは、たとえば次のように、さまざまな例外を処理している場合です。

try
{
   ...
}
catch(SQLException sex)
{
   //Do Custom Logging 
   //Don't throw exception - swallow it here
}
catch(OtherException oex)
{
   //Do something else
   throw new WrappedException("Other Exception occured");
}
catch
{
   System.Diagnostics.Debug.WriteLine("Eeep! an error, not to worry, will be handled higher up the call stack");
   throw; //Chuck everything else back up the stack
}

C＃（C＃6より前）は、CILの「フィルターされた例外」をサポートしていません。VBがサポートしているため、C＃1-5で例外を再スローする理由の1つは、catch（）の時点で十分な情報がないことです。実際に例外をキャッチしたいかどうかを判断します。

たとえば、VBでは次のことができます

Try
 ..
Catch Ex As MyException When Ex.ErrorCode = 123
 .. 
End Try

...これは、異なるErrorCode値を持つMyExceptionsを処理しません。v6より前のC＃では、ErrorCodeが123でない場合、MyExceptionをキャッチして再度スローする必要がありました。

try 
{
   ...
}
catch(MyException ex)
{
    if (ex.ErrorCode != 123) throw;
    ...
}

C＃6.0以降では、VBと同じようにフィルタリングできます。

try 
{
  // Do stuff
} 
catch (Exception e) when (e.ErrorCode == 123456) // filter
{
  // Handle, other exceptions will be left alone and bubble up
}

次のようなコードを持つ私の主な理由：

try
{
    //Some code
}
catch (Exception e)
{
    throw;
}

キャッチにブレークポイントを設定できるようにするため、インスタンス化された例外オブジェクトがあります。開発/デバッグ中にこれをよく行います。もちろん、コンパイラーはすべての未使用のeについて警告を出します。理想的には、リリースビルドの前に削除する必要があります。

ただし、デバッグ中は便利です。

例外を再スローする正当な理由としては、例外に情報を追加したり、独自の作成で元の例外をラップしたりすることが考えられます。

public static string SerializeDTO(DTO dto) {
  try {
      XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
      StringWriter sWriter = new StringWriter();
      xmlSer.Serialize(sWriter, dto);
      return sWriter.ToString();
  }
  catch(Exception ex) {
    string message = 
      String.Format("Something went wrong serializing DTO {0}", DTO);
    throw new MyLibraryException(message, ex);
  }
}

これは例外をまったく処理しないこととまったく同じではありませんか？

厳密には同じではありません。例外のスタックトレースをリセットします。これはおそらく間違いであり、したがって悪いコードの例であることに私は同意します。

あなたはexを投げたくない-これはコールスタックを失うからだ。例外処理（MSDN）を参照してください。

そして、はい、try ... catchは何の役にも立ちません（コールスタックが失われることを除いて、実際にはもっと悪いです-何らかの理由でこの情報を公開したくない場合を除きます）。

人々が言及しなかった点は、.NET言語は実際には適切な区別をしていませんが、例外が発生したときにアクションを実行する必要があるかどうか、およびそれを解決するかどうかは、実際には異なる質問です。解決する見込みのない例外に基づいてアクションを実行する必要がある多くの場合があり、例外を「解決」するために必要なのは、スタックを特定のポイントまで巻き戻すことだけである場合があります。それ以上のアクションは必要ありません。 。

「処理」できるものだけを「キャッチ」する必要があるという一般的な知識があるため、例外が発生したときにアクションを実行する必要がある多くのコードはそうではありません。たとえば、多くのコードはロックを取得し、保護されたオブジェクトを「一時的に」その不変条件に違反する状態にしてから、オブジェクトを正当な状態にしてから、他の人がオブジェクトを見る前にロックを解除します。オブジェクトが危険なほど無効な状態にあるときに例外が発生した場合、一般的には、オブジェクトがその状態のままでロックを解除します。はるかに良いパターンは、オブジェクトが「危険な」状態にあるときに発生する例外を明示的にロックを無効にすることです。これにより、それを取得しようとすると、すぐに失敗します。

ほとんどの.NET言語では、コードが例外に基づいてアクションを実行する唯一の方法は、catchそれを（例外を解決しないことがわかっている場合でも）コードに対して実行し、問題のアクションを実行してから再実行することthrowです。コードがスローされた例外を気にしない場合に考えられる別のアプローチはok、try/finallyブロックでフラグを使用することです。セットokにフラグをfalseブロックする前に、とにtrueブロックが終了する前に、および任意の前にreturnブロック内だという。次に、内でfinally、okが設定されていない場合は、例外が発生したと想定します。このようなアプローチは、意味的にはcatch/ よりも優れていますが、throw見苦しく、メンテナンスが容易ではありません。

これは、ライブラリまたはDLLのプログラミング関数の場合に役立ちます。

この再スロー構造を使用して、意図的にコールスタックをリセットし、関数内の個々の関数からスローされた例外を確認する代わりに、関数自体から例外を取得できます。

これは、スローされた例外がよりクリーンになり、ライブラリの「ルーツ」に入らないようにするために使用されていると思います。

キャッチスローの1つの考えられる理由は、スタックのより深いところで例外フィルターを無効にすることです（ランダムな古いリンク）。しかし、もちろん、それが意図であった場合、そこにそのように言うコメントがあります。

これは、catchブロックで何をしているのか、および呼び出し元のコードにエラーを渡したいかどうかによって異なります。

言ってCatch io.FileNotFoundExeption exから、別のファイルパスなどを使用しても、エラーが発生する場合があります。

またやってThrowの代わりに、Throw Exあなたは完全なスタックトレースを維持することができます。Throw exは、throwステートメントからスタックトレースを再開します（それが理にかなっていると思います）。

他の多くの回答は、例外を再スローする必要がある理由の良い例を提供していますが、「最後の」シナリオについて言及している人はいません。

この例としては、カーソルを（たとえば、待機カーソルに）設定するメソッドがあり、そのメソッドにいくつかの終了点（if（）return;など）があり、カーソルがメソッドの終わり。

これを行うには、すべてのコードをtry / catch / finallyでラップします。最終的に、カーソルを右カーソルに戻します。有効な例外を埋めないように、キャッチで再スローします。

try
{
    Cursor.Current = Cursors.WaitCursor;
    // Test something
    if (testResult) return;
    // Do something else
}
catch
{
    throw;
}
finally
{
     Cursor.Current = Cursors.Default;
}

あなたが投稿したコードの例では、実際には、例外がキャッチされても意味がありません。キャッチで何も行われず、再スローされるだけです。実際には、コールスタックが失われるので、害を及ぼします。 。

ただし、例外が発生した場合、例外をキャッチして、ロジックを実行して（ファイルロックのSQL接続を閉じる、または単にログを記録するなど）、処理する呼び出しコードに例外をスローします。ビジネスレイヤーを実装するコーダーで例外を処理する必要がある場合があるため、これはビジネスレイヤーではフロントエンドコードよりも一般的です。

繰り返しますが、投稿した例で例外をキャッチしても意味がありません。そのようにしないでください！

申し訳ありませんが、「改善されたデザイン」としての多くの例は依然としてひどいにおいがするか、非常に誤解を招く可能性があります。{}を試してみると{ログ; throw}はまったく意味がありません。例外ロギングは、アプリケーション内の中央の場所で行う必要があります。例外はとにかくスタックトレースを泡立たせます、なぜそれらをシステムの境界のどこかに、そして近くに記録しませんか？

コンテキスト（つまり、1つの例ではDTO）をログメッセージにシリアル化する場合は注意が必要です。ログファイルにアクセスできるすべての人の手に渡りたくない機密情報を簡単に含めることができます。また、例外に新しい情報を追加しないと、例外の折り返しのポイントがわかりません。古き良きJavaにはそのためのポイントがあり、呼び出し元は、コードを呼び出すときにどのような例外が予想されるかを知る必要があります。.NETにはこれがないため、ラッピングは、私が見たケースの少なくとも80％では何の効果もありません。

他の人が言ったことに加えて、キャッチと再スローはノーオペレーションではないことを示す関連質問への私の回答を参照してください（VBにありますが、一部のコードはVBからC＃で呼び出すことができます）。

シナリオcatch-log-rethrowに関するほとんどの回答。

代わりにあなたのコードでそれを書き込むので、特に、AOPを使用することを検討しPostsharp.Diagnostic.Toolkit OnExceptionOptions IncludeParameterValueとIncludeThisArgumentで

経由の例外の再スロー throwは、現在の例外を処理する特定のコードがない場合、または特定のエラーケースを処理するロジックがあるが、他はすべてスキップする場合に便利です。

例：

string numberText = "";
try
{
    Console.Write("Enter an integer: ");
    numberText = Console.ReadLine();
    var result = int.Parse(numberText);

    Console.WriteLine("You entered {0}", result);
}
catch (FormatException)
{
    if (numberText.ToLowerInvariant() == "nothing")
    {
        Console.WriteLine("Please, please don't be lazy and enter a valid number next time.");
    }
    else
    {
        throw;
    }
}    
finally
{
    Console.WriteLine("Freed some resources.");
}
Console.ReadKey();

ただし、これを行う別の方法として、catchブロックで条件句を使用する方法もあります。

string numberText = "";
try
{
    Console.Write("Enter an integer: ");
    numberText = Console.ReadLine();
    var result = int.Parse(numberText);

    Console.WriteLine("You entered {0}", result);
}
catch (FormatException) when (numberText.ToLowerInvariant() == "nothing")
{
    Console.WriteLine("Please, please don't be lazy and enter a valid number next time.");
}    
finally
{
    Console.WriteLine("Freed some resources.");
}
Console.ReadKey();

.NETランタイムは例外オブジェクトを再スローする前に再構築する必要がないため、このメカニズムは例外を再スローするよりも効率的です。