状況に対する見方を少し変えると、この問題をより簡単に解決できると思います。
- あなたはフレームワークを扱っています。それを外部フレームワークと呼びましょう。
- 一方、フレームワーク - 内部フレームワークのラッパーを作成しています。
- コード (クライアント アプリケーション) は内部フレームワークを使用しており、それが問題のドメインに使用される機能を提供すると想定しています。私が理解しているように、そして私が信じているように、クライアントアプリケーションは外部フレームワークについて何も考えるべきではありません。
内部フレームワークの機能は明確に概説され、最終決定されていますか? それともそれも変化していますか?
変更されている場合 (おそらく外部フレームワークが原因)、内部フレームワークは開発中です。つまり、クライアント アプリケーションは、内部フレームワークが最初のバージョンの準備が整ったことをアナウンスする準備ができるまで (おそらく外部フレームワークが完了した後) 待機する必要があります。
エラー処理:
アプリケーションのエラーは契約のように機能します。関数の呼び出し元は、特定の例外的な状況、および特定の種類のエラーのみを想定しています。入力パラメーターや戻り値と同様に、考えられるエラーはそれぞれ関数ごとに事前定義され、文書化されています。
あなたにとっての意味:
- 内部フレームワークの最終設計を定義します (早ければ早いほど良い)。
- 内部フレームワークの各関数がスローできるエラーの種類を決定します。
- クライアント アプリケーションから内部フレームワークを使用し、予想される文書化された例外のみを想定します。内部フレームワークから予期されていないものを試したりキャッチしたりしないでください。基本的には契約に従います。
- エラー コードが変更されても、内部フレームワークの関数の概念は変更されません。以前にスローしたのと同じ種類のエラーをスローする必要があります (コントラクトに従って)。変更する必要がある唯一の部分は、新しいコードを予想される (縮小された) エラーの 1 つに変換する方法です。うまくいく方法で解決できます。
最後の仮定が正しいのはなぜですか? 内部アプリケーションの設計は最終的なものであり、変更されることはないと述べたからです。エラー コントラクトも最終設計の一部です。
例:
//external.
int Say(char* message);
//internal.
///<summary>
/// can throw (CONTRACT): WrongMessageException, SessionTimeOutException
void Say(string message) {
int errorCode = External.Say(message);
//translate error code to either WrongMessageException or to SessionTimeOutException.
}
翻訳できませんか?現在の契約エラーまたは外部フレームワークのいずれかで何か問題があります。おそらくプロセスを終了する必要がありますか? 何かがうまくいかなかった、予期しない!!!
//client.
...
try {
Internal.Say("Hello");
}
catch (WrongMessageException wme) {
//deal with wrong message situation.
}
catch (SessionTimeOutException stoe) {
//deal with session timeout situation.
}
何か質問があれば教えてください。
エラー コードを例外に変換する:
これは明らかに、エラー コードごとにある種の分類です。カテゴリは各宛先例外にすることができ、例外は関数によって分類できます。これはまさにエラー コントラクトの意味です。関数ごとに例外を分類します。エラー コードを例外別に分類します。
以下は、このための疑似構成です。これを分類方法の最初のアイデアとして考えてください。
category Say [can throw]: { WrongMessageException, SessionTimeOutException }
category WrongMessageException [by error code]: { 100, 101 }
category SessionTimeOutException [by error code]: { 102, 103, 104 }
もちろん、そのような種類のインプレッション用のパーサーを作成する必要はありません (これは人間が読める疑似構成でした)。XML または任意の種類のソースを使用して同様の文を保存できます。これは、エラー変換ルールと関数コントラクトを構成するのに役立ちます。
参照
本: Jeffrey Richter - C# による CLR、第 3 版。第 20 章 - 例外と状態管理。サブチャプター - ガイドラインとベスト プラクティス。サブサブチャプター - 「契約」を維持するための実装の詳細の非表示。
この章では、例外をコントラクトとして説明し、関数によってスローされたコントラクトを分類する方法について説明します。これにより、ここで提供される説明の正確性と信頼性を確認できます。