私が執筆している図書館では、非常にめったに実行されない方法がいくつかあります。私が車両をモデリングしているとき、（例外的な）方法の1つは、非常にまれな分解エンジンです。私はこのメソッドで例外をスローする必要がありますか？これにより、車両が使用できなくなります。この例で例外をスローするのに最適なのはどこですか？
.NET設計フレームワークガイドラインブックを読んで、メソッドが実行を完了できない場合にのみ例外が発生する必要があることを示しています。実際のエンジンのクラックされたメソッドは常に完了しますが、私のメソッドの1つ、たとえばエンジンを始動する（このメソッドはエンジンにストレスを与える手段としてのエンジン始動量を格納します）が呼び出され、クラックされたエンジン、どこに（もしあれば）私は例外をスローする必要がありますか？
コードやランタイムの問題を強調する例外をスローする必要があると考えます。これは実際には正常なシステムロジックです（この意味で、クラックされたエンジンはコードの問題ではなくモデル状態です）。
代わりに、モデリングしているシステムのコンテキストに合ったフィードバックメカニズムが必要です。私はあなたのCarモデルが変数を持っている必要があります信じて
はそうのように宣言：あなたはcrackedEngine(Car car)メソッドへの呼び出しを行うとき、それは順番にbool
これを返します
bool isEngineCracked;
はあなたをできるようになりますエンジンの状態チェックを行い、エンジンが機能しているかどうかを確認します。
もしシステム（またはサブシステム）は試験エンジンに設計されており、エンジンの状態が割れている場合は、通常のシステムの処理の結果として予想される、システム内の通常の状態であり、それはありません例外。システムが生産エンジンで使用されていて、エンジンがクラッキングされたときにシステム全体が機能しなくなる場合、設計機能（クレートを持ち上げ、車両を前進させる）、クラッキングされたエンジンは例外です。
システム全体が両方の組み合わせである場合、エンジンテスターとして機能するサブシステム内で（クラッキングされたエンジンは、システムが管理、監視、報告および診断するように設計された状態の1つです。 ）、それは定義された状態で、例外ではなく、システムの残りの部分では例外でなければなりません...そして、これらの2つのサブシステム間のインタフェースに、エンジンの状態を検出する必要があります。それを例外に変換する（逆の場合もあります）
フィードバックメカニズムのビットを教えてください（それは何ですか）？ – dotnetdev
それは本当に残りのコードに依存しているので、言うことは難しいでしょう - しかし、あなたのシステムはそれに関連する条件付きロジックを持つ状態の感覚を持っていると思いますか？ EngineState.Crackedがそこに収まるかもしれません。Engine.Cracked（明らかに疑似コードがあります）の場合、Engine.Startを実行します。 –
私はあなたが何を意味するかを見ます。私はそのアプローチに従うことができますが、カーが動いているときにクラックされた例外が発生することがあります。その時点で例外がスローされるべきです（システムが機能しなくなるため）。 – dotnetdev