6

私は以下の質問や記事を深く読み、議論しました。現在および過去に他の多くの質問や記事を読みました。

いつtry/catchブロックを使用しますか？

完全にtry/catch内のメインメソッドコード：それは悪い習慣ですか？

TryCatchブロックを使用する場合

この記事を私の組織での例外処理のコーディング標準にします！とても素敵なものですが、私には答えませんでした：http: //www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET

クリーンなコードを作成するためにcatchブロックを試すためのベストプラクティスは何ですか？

JavaまたはC＃での例外管理のベストプラクティス ここで：私はこのステートメントが好きではありませんでした:(すべての可能な場所ですべての例外をキャッチしようとすべきではありません。

メソッド内の複数のTry/Catchブロックを組み合わせる必要があります

try-catchステートメントでコードのブロックを囲む必要がある場合に問題が発生します。コードを囲む必要があるのは障害のあるコードであることがわかっています。また、確認できる内容を確認する必要がありますが、たとえば、次のことを行う必要があります。テキストファイルに行を書き込む場合は、ファイルが存在するかどうかを確認し、書き込み権限がある場合は、ディスクにスペースがあるかどうか、またはディスクが書き込み可能かどうかを確認する必要があります。スペース、ファイルの書き込み中に何かが発生した場合（他のアプリやスレッドがスペースを使用したか、リムーバブルドライブが削除された場合）はどうなりますか？それらをチェックして、IOExceptionとSecurityExceptionおよびその他の潜在的な例外を処理した場合のベストプラクティスですか？ 、またはtry-catchなしでのみチェックする必要がありますか？

別の例：EntityFrameworkを使用してデータベースにアクセスしています。何かにアクセスするとデータベースに接続する可能性がある場合、接続を閉じて開こうとする必要があることはわかっていますが、このステートメントで失敗を引き起こす可能性のあるものはたくさんあります。データベースがリムーバブルドライブ上にある可能性があります。このドライブが読み取り中に削除される可能性があります。DBMSのサービスが何らかの理由で停止する可能性があります。スペース例外がスローされない可能性があります。コードを実行しようとすると、データベースのスキームが変更される可能性があります。 ****理由、コードが失敗するのを防ぐにはどうすればよいですか、確認できるすべてのことを確認して続行できますか？または、チェックしたにもかかわらず、期待できる例外に対してtry catchを使用する必要がありますか？

一般的な回答ではなく、あなたの回答の参照を教えてください！

編集

そして、必ずこれを読んでください：http: //msdn.microsoft.com/en-us/library/seyhszts.aspx

4

2 に答える 2

4

良い質問！あなたのリンクの1つ（Daniel Turini）は私のお気に入りの1つです。私の思考がいくらかまっすぐになる必要があるとき、私は何度も何度もそれに戻ります。

例外処理に対する私の態度を表現する良い方法は、次のとおりです。処理できる例外のみを処理します。つまり、発生する可能性のある例外に対応して何をすべきかを理解し、これをコードに実装することはできません。対処できる「予想される」例外がいくつかありますが、これらに対応してコードが実行するのは、それ自体が設計上の決定です。私見では、これらを処理する際の優先事項は、アプリのシャットダウン後に混乱を残さないことです（または、少なくとも、関与していた特定のトランザクションを取り消すことはありません）-シャットダウンするため、アプリケーションが関係なく続行できるようにすることはできません優雅な「理由はわかりませんが、この例外が発生しました」という通知（ログ/ITメール/MsgBoxなど）はどういうわけか「

この種の設計の正反対は、アプリを一種の「核-アルマゲドン-生存者」にしようとする一種の例外処理です。 しようとしています...ネットワークファイルサーバーがダウンしていると想定してIOエラーに応答し、C：ドライブで設計されていない方法で動作しようとするコードを見てきました。そして、SELECT FROM ATableを試みるコード：テーブルが存在しない場合は、それを作成します!!! 誰かがこのようなコードを書くたびに、赤ちゃんのポッサムは死にます。

Turiniは「例外を飲み込まないでください」と言います。私が考えているのはこれの延長です：私見あなたは、既知の明確なタイプの例外に応答しても、既知の原因でアプリを続行させることに非常に注意する必要があります：これでさえ「飲み込む」例外を構成するからです。それをしなさい、しかしそれを注意深くそしてよくしなさい。

したがって、私の考えでは、一般的な「その他の場合」の例外ハンドラーの余地は常にあります。これは、何が起こったかの詳細をログに記録し、アプリをシャットダウンすることで、より高い権限（人間）に決定を委任します。

私の2c..

于 2012-11-18T13:28:32.893 に答える
0

IMHO：アプリケーションがクラッシュするのを防ぐために、アプリケーションの最終レイヤーですべての例外をキャッチし（UI、コンソールアプリの本体、または何らかのサービスメソッドの本体など）、次の場合に処理します。少なくともログに記録することはできますが、内部レイヤーでは、完全に処理することがわかっている例外のみをキャッチし、完全に処理する方法がない例外をスローまたはラップします。ただし、コードに明確な境界がない場合レイヤー間（私の場合も同じ）では、例外が発生する可能性がある場合は常にそれを処理し、このアプリを適切に構築された方法でリセット（書き換え）してみてください（すぐに実行します！）。

于 2012-11-18T15:15:23.320 に答える