問題タブ [rethrow]

例外をキャッチして再スローするときに考慮すべきベストプラクティスは何ですか？ExceptionオブジェクトInnerExceptionとスタックトレースが保持されていることを確認したいと思います。次のコードブロックの処理方法に違いはありますか？

対：

例外をスローすることは、UI または例外をログに記録してユーザーに通知する場所にバブルを戻すための良い方法だと思いました。

resharper が冗長であると言うのはなぜですか?

キャッチ内の次の append() により、再スローされた例外が呼び出された append() の効果を確認できますか?

同様に、このように書き直すと、実際の例外が myErr によって派生した場合にビット スライスが発生しますか?

私の同僚は、.Netに切り替える経験豊富なC++ハッカーです。彼らが意図せずに犯す間違いの1つは、次のようなコードを書くことです。

私はこれが多くの場所で行われているのを見てきました。スタックトレースを切り取ることが役立つ状況は、私にはあまり考えられません。それはコメントに値する例外的な状況であるべきだと思います。私が間違っている場合は私を訂正してください。スタックトレースをカットする場合は、次のことを行う方が常に良いと思います。

とにかく、私がやりたいのは、そのようなすべてのケースを検出し、警告を出すことです。このため、正規表現検索は役に立ちません。

StyleCop（私が持っているバージョン4.3.3.0）などのツールを使用する必要があります。今はVS2008を使用していますが、間もなくVS2010に切り替えます。

私が探していることを達成する方法について何か考えはありますか？

ネット上、特に SO に関する多くのドキュメントを参照しています。たとえば、C# で例外を再スローする適切な方法は何ですか? 「throw e;」には違いがあるはずです。そして「投げる」。

しかし、から: http://bartdesmet.net/blogs/bart/archive/2006/03/12/3815.aspx、

このコード:

次の結果が得られます。

これはブログ投稿と完全に矛盾しています。

http://crazorsharp.blogspot.com/2009/08/rethrowing-exception-without-resetting.htmlのコードでも同じ種類の結果が得られます。

元の質問: 何が間違っていますか?

更新: .Net 3.5 / csc.exe 3.5.30729.4926 と同じ結果

SUMUP : すべての回答が素晴らしかったです。ありがとうございます。

その理由は、64 ビット JITter による効果的なインライン化です。

答えを 1 つだけ選択する必要がありましたが、LukeHの答えを選択した理由は次のとおりです。

• 彼は、インライン化の問題と、それが私の 64 ビット アーキテクチャに関連している可能性があるという事実を推測しました。

• 彼は、この動作を回避する最も簡単な方法である NoInlining フラグを提供しました。

しかし、この問題は別の問題を引き起こします。この動作はすべての .Net 仕様 (CLR 仕様と C# プログラミング言語仕様) に準拠していますか?

UPDATE : この最適化は、次のように準拠しているようです: Throw VS rethrow : same result? (ありがとう0xA3 )

よろしくお願いします。

次のようなコードがある場合：

元の例外は、noteError（）の下部フレーム内の両方の場所からスローされますか？

「特定の」例外（FormatException ^またはOverflowException ^）をキャッチしてから、それを再スローして「一般的な」例外（Exception ^）キャッチブロックでキャッチしようとしています。

実行すると、入力を通じてフォーマットの例外が与えられます。次に、ダイアログ ボックスに次のエラーが表示されます。「break」をクリックすると、232 行目に移動します。

部分的なコードは次のとおりです。

「throw;」で例外を再スローしますが、スタック トレースが正しくありません。

正しいスタック トレースは次のようになります。

しかし、私は得る：

しかし、15 行目は「throw;」の位置です。これを .NET 3.5 でテストしました。

try-catch ステートメント内に try-catch ステートメントがあります。内側の catch はエラーをキャッチしますが、スローによってエラーが out catch ステートメントでキャッチされることはありません。簡単に言うと、私のスクリプトは次のようにフォーマットされています。

スクリプトを実行するとエラーは発生しませんでしたが、入力しようとしていた SQL Server データベースにデータが不足していることに気付きました。デバッグでスクリプトを再実行すると、関数「putStuffInDB」にエラーがあり、catch ブロックでキャッチされました。しかし、私がステップしたとき、メッセージは外側の catch ブロックに「スロー」されませんでしたが、finally ブロックを処理して終了しました。

私は明らかに、私が見ていないものを見逃しています。過去に C# でこの構造を使用したことがありますが、エラーが外側の catch ブロックに「渡される」という問題はありませんでした。

このアプローチは大丈夫ですか？例外を正しく処理していますか? 私のクラスを見てください：