問題タブ [exception-handling]

データ アクセス層の奥深くまたはさらに上位 (たとえば、ADO.net 操作内など) で発生するエラーは、エンド ユーザーにとってほとんど意味がありません。これらのエラーを UI にバブルアップして表示するだけでは、通常、エンド ユーザーのフラストレーション以外には何も達成されません。

私は最近、このようなエラーを報告するための基本的な手法を採用しました。これにより、エラーをキャッチし、少なくともエンドユーザーが何が失敗したかを理解できるように、少なくともユーザーフレンドリーなテキストを追加します。

これを行うために、各特定の関数 (たとえば、データ アクセス レイヤーのフェッチ関数など) 内で例外をキャッチし、失敗した関数とおそらく原因についてユーザー フレンドリーなテキストで新しいエラーを発生させますが、元の関数を埋め込みます。その新しい例外の「内部例外」としての新しい例外の例外。

これは、必要に応じて各レイヤーで発生し、下位レベル関数の各コンシューマーが独自のコンテキストをエラー メッセージに追加することで、UI に到達するエラー メッセージがますますユーザー フレンドリーになります。

エラーが UI に到達すると (必要に応じて)、ネストされた例外を繰り返し処理して、最初にどの操作が失敗したかをユーザーに通知するだけでなく、実際に何がうまくいかなかったのかについての技術的な情報も提供するエラー メッセージを表示できます。

例えば

「リクエストされた顧客名のリストを表示できませんでした。」

「データベースにエラーが発生したため、要求した顧客のリストを取得できませんでした。」

「顧客リストの取得中にデータベースへの接続中にエラーが発生しました」

「ユーザー xx のログインに失敗しました」

私の質問はこれです: これはひどく非効率的ですか (ネストされたすべての例外)? 私はそれがベストプラクティスではないと思うので、同じことを達成するために何をすべきですか?

基本的に、特定の条件によって .net が finally ブロックを通過してしまうと聞いたことがあります。それらの条件を知っている人はいますか？

私は次のコードを何度も見ました：

例外を再スローする目的を説明していただけますか？例外処理のパターン/ベストプラクティスに従っていますか？（「発信者通知」パターンと呼ばれることをどこかで読んだことがありますか？）

デストラクタで、例外が現在処理されているかどうかを判断する方法はありますか?

私の経験不足を明らかにするための質問があります。私はDoSomething()メソッドを持っています。これは、うまく処理できない場合に例外をスローします。失敗した場合は、精度の低いメソッドDoSomethingAbout()を数回試して、十分に適切な解決策が見つかることを願っています。これも失敗した場合は、最終的にDoSomethingInaccurateButGuaranteedToWork()を呼び出します。3 つすべてが、このオブジェクトに属するメソッドです。

2 つの質問: まず、この (確かに醜い) パターンは受け入れられるでしょうか、それとももっとエレガントな方法がありますか?

第二に、例外をスローする可能性があることを考えると、DoSomethingAbout()を呼び出した回数を追跡する最良の方法は何ですか? 私は現在、オブジェクトに変数 iNoOfAttempts を保持しており、try ブロックをネストしています...これは恐ろしいことであり、恥ずかしいことです。

引数なしでcatchを使用するのは悪い形式であると人々が言うのを見たことがあります。特に、そのcatchが何もしない場合はそうです。

ただし、これは適切な形式と見なされます。

私が知る限り、finallyブロックにクリーンアップコードを配置することと、try..catchブロックの後にクリーンアップコードを配置することの唯一の違いは、tryブロックにreturnステートメントがあるかどうかです（この場合、finallyのクリーンアップコードは実行しますが、try..catchの後のコードは実行しません）。

そうでなければ、最終的に何がそんなに特別なのですか？

同社のシステムの例外処理の 1 つを調べたところ、いくつか興味深いことがわかりました。

ほとんどのコード ブロック (すべてではないにしても) は try/catch ブロック内にあり、catch ブロック内で新しい BaseApplicationException がスローされています。これはエンタープライズ ライブラリから来ているようです。これを行うメリットが見当たらないので、ここで少し困っています。(例外が発生するたびに別の例外をスローする) しばらくシステムを使用している開発者の 1 人は、そのクラスが例外の発行 (メールなどの送信) を担当しているためだと言いましたが、彼はそれについてあまり確信が持てませんでした。しばらくコードを調べてみたところ、環境に関する情報を収集し、それを公開するだけであると確信しています。

私の質問は次のとおりです。もしそうなら、なぜですか？メリットは何ですか？

私の個人的な意見では、HttpModule を使用し、Application イベントの Error イベントにサインアップし、モジュール内で必要なことを行う方がはるかに簡単です。この道を行くとしたら、何かを逃すでしょうか？欠点はありますか？

あなたの意見は大歓迎です。

例外が定期的にスローされることを期待して、それらをフロー ロジックとして使用することは悪いことだと常に感じていました。例外は、まあ、「例外」であるべきだと感じます。例外を予期して計画している場合、少なくとも .NET ではコードをリファクタリングする必要があることを示しているように思われます...
ただし。最近のシナリオで私は一時停止しました。これは少し前に msdn に投稿しましたが、それについてもっと議論したいと思います。ここは完璧な場所です!

したがって、他のいくつかのテーブルの外部キーを持つデータベース テーブルがあるとします (最初に議論を引き起こしたケースでは、それを指す 4 つの外部キーがありました)。ユーザーが削除できるようにしたいが、外部キー参照がない場合に限る。カスケード削除したくありません。
私は通常、参照があるかどうかを確認するだけで、参照がある場合は、削除する代わりにユーザーに通知します。関連するテーブルはオブジェクトのメンバーであるため、LINQ でそれを書くのは非常に簡単でリラックスできます
。そのレコードを指す結果行があるかどうかを確認するために、4 つのテーブルすべてをヒットする可能性があります。データベースをヒットすることは、明らかに常に比較的高価な操作です。

このプロジェクトのリーダーは、コード 547 (外部キー制約) で SqlException をキャッチし、そのように処理するように変更するように私に依頼しました。

私は…
抵抗しました。

しかし、この場合、4 つのテーブル ヒットを飲み込むよりも、例外関連のオーバーヘッドを飲み込む方がおそらくはるかに効率的です。子供がいないとき...
さらに、データベースは参照整合性の処理を担当する必要があり、それがその仕事であり、うまく機能します...
だから彼らは勝ち、私はそれを変更しました。

あるレベルでは、それでも私には間違っていると感じています。

例外を期待して意図的に処理することについてどう思いますか? 事前に確認するより効率が良さそうな場合は大丈夫ですか？次の開発者があなたのコードを見て混乱することはありますか?それとも混乱が少ないでしょうか? データベースは、開発者がチェックを追加することを考えていない可能性のある新しい外部キー制約を認識している可能性があるため、より安全ですか? それとも、ベスト プラクティスとは正確には何だと考えているかという視点の問題ですか?

値をチェックするif条件があり、新しいNumberFormatExceptionがスローされます

これをコーディングする他の方法はありますか

この記事では、構造化された例外処理がよくない理由について概要を説明しています。この記事で言及されている問題を回避しながら、サーバーのクラッシュを防ぐ堅牢性を確保する方法はありますか?

約 400 人の接続ユーザーを同時に実行するサーバー ソフトウェアがあります。しかし、クラッシュが発生した場合、400 人のユーザー全員が影響を受けます。構造化された例外処理を追加し、しばらくは結果を楽しみましたが、サーバー全体がハングするクラッシュが発生したため、最終的に削除する必要がありました (クラッシュして再起動するよりも悪いことです)。

だから私たちはこれを持っています：

• SEH の場合: ほとんどのクラッシュで問題が発生するのは 400 人中 1 人のユーザーのみ
• SEH を使用しない場合: いずれかのユーザーがクラッシュすると、400 人全員が影響を受けます。
• ただし、SEH を使用すると、サーバーがハングすることがあります。400 人すべてが影響を受け、将来接続を試みるユーザーが影響を受けます。