ブルースへの思い-もう一度例外処理について

すでにC＃での例外処理について多くのことを書いており、うまく書かれており、いくつかの場所で詳細に書かれていますが、この問題に対してはささやかな貢献をしようとします。 この記事は、問題への可能なアプローチである非常に条件付きの概念のフレームワーク内でより良く理解し体系化するための単なる試みです。 私の意見では、例外処理の優れたプラクティスはかなり不十分にしかカバーされておらず、コード内の例外的な状況をいつ、どのように、どこで処理するかを完全には把握していません。



開発者は、プロジェクトの最初から開発のすべての段階をカバーする特定の「ロードマップ」を念頭に置いておくとよいでしょう。 「死は人生の一部です」と、お母さんはフォレストガンプに語りました。不測の事態はシステムの通常の機能の一部です。プロジェクトの構造に有機的に織り込まれていることは、フルタイムの機能セット全体を実装することと同じくらい重要だと思います。



いつものように、まず用語を定義してみてください。 MSDNをご覧ください-「 C＃言語の例外処理機能は、プログラムの実行中に発生する予期しない状況または例外的な状況に対処する方法を提供します 。」という表現の非常に興味深い場所は、 予期しない状況または例外的な状況です。 一見同義語のように聞こえますが、考えてみると、違いは非常に明白です。特定のユースケースの実行中の例外的な状況と、それ自体が例外的な状況である「システムユースケース」というシステム動作です。 私が意味することをより詳細に説明します。 標準設計ワークフローは、大まかに言って、仕様から名詞をアクターエンティティに投影し、動詞をユースケース図エンティティに投影するユースケース図から始まります。 そして、スキームの形式化への慎重なアプローチにより、システムの各新しい状態へのエントリー（ユースケースで示されています）、およびその終了は、前提条件と事後条件の充足に従って発生する必要があります。 状態ごとに、このセットは一意であり、一般的な機能は、このセット全体の実装により、システムが正しい一貫した状態になることです。 したがって、条件は設計段階で理論的に既に明確に定義されている必要があるため、それらの不一致は原則として例外的な状況と呼ばれるものを生じさせます。



さらに、単に「武士の原理」のような素晴らしい概念に言及する必要があります。 その本質は、最も明確に決定された予測可能なコード動作を取得することです。 ArgumentExceptionの助けを借りて、不適切な入力データのセット（前提条件のトピックのバリエーション）をフィルターで除外するフィルターの外観があり、さらにコードに沿って、すべての疑わしい場所も例外で囲まれているため、コードは可能な限り美しく予測可能にクラッシュします この手法は、すでにコーディング段階を指します。たとえば、提供された機能の最も安全な実装を指します。 ここでは、ビジネス要件を処理する際に明確に定義された前提条件と事後条件はなく、特定のサービスを提供するコードと、これらのサービスを消費するコードがあるだけなので、 予期しない状況に言及する方がはるかに適切です。



ここで主なものに-実際の観点からこれらすべてから続くもの。 一連の事前条件と事後条件の違反について通知する第1種の例外は、できる限りクライアントの近くで処理する必要があります。クライアント部分に最も近いコードは、予想される動作を最もよく知っています。 このような例外を処理する責任を負うのはこのコードです。 異なる種類の予期しない状況の例外については、1つまたは別の機能を実装するコード（たとえば、データベースを使用している場合はリポジトリのコード）が機能するはずです。 そして、この場合、それどころか、ハンドラーは例外の場所に可能な限り近くなければなりません。



一般的に、この小さなメモは、再び結論を出すのではなく、システムの動作の「ネガティブ」なシナリオと、それらを最良の方法で操作する方法について考えているだけです。