別の比phor、またはむしろ設計原理は、関数とそれを呼び出すコードとの間の「契約」を記述するように設計された「 サムライ原理 」であり、以下で構成されます。 特定の作業単位を実装するすべての機能は、武士が住んでいるのと同じ名誉の「武士道」に従う必要があります。 そのため、theは彼の「名誉の綱領」と矛盾するタスクを実行せず、「わいせつな」提案で彼に近づくと、目を瞬く時間がある前に彼はあなたの頭を吹き飛ばします。 しかし、サムライがビジネスに取り掛かる場合、彼はそれを最後まで持っていくと確信できます（**）。
オープン機能はすべて同じ原則に従う必要があります。 彼女が自分の前提条件に違反する不適切な入力（つまり、彼女の名誉のコード）に「スリップ」した場合、彼女は例外を除いてこれを明確に言う必要があります（これはあなたがこれを責めるため、頭の破壊の類似物です）。 しかし、引数が有効で、正しい状態で呼び出された場合、呼び出し元のコードは結果を確認できます。関数は成功するか、「クラッシュ」します。 functionのような機能は、日曜大工の原則に従う必要がありますが、saが恥を避けるために切腹をする場合、その機能を果たすことができない場合、機能は例外で「落ちる」べきです。
この一見シンプルな原則は、例外処理の多くの難しい質問への答えを提供します。 関数の引数をチェックし、それらが正しくない場合はどうすればよいですか？ この関数の内部で発生する例外を飲み込む必要がありますか？ 何かがうまくいかず、関数が仕事を行えない場合、 nullまたは空のリストを返す必要がありますか？ （***）
関数が無効な入力パラメーターを受け取るか、不正な状態で呼び出された場合、例外をスローします。 内部関数が処理を行うときに例外をスローする場合、これは関数がその処理を実行できないことを意味します。 この場合、例外をスローするか、別の例外にラップします。
この原則から、例外を「飲み込む」ことは悪いということになります。実際、あなたはあなたの問題を呼び出し元のコードの目から隠し、外部コードがそれについて学習するのを防ぐからです。 あなたが自分自身に過度に取り組む必要はありません。あなたの仕事に失敗し、武士の原則に従うことを決めたとき、「クライアント」に頭痛を与え、「あなたの体」をどうするか（つまり例外をどうするか）を任せます。
呼び出しコードは空のオブジェクトが有効な値であるか、受信中にエラーが発生したかを判断できないため、例外の場合にnullオブジェクトを返すことも危険な方法です。
public SomeEntry ReadEntryById( int id)
{
try
{
// SomeEntry
}
catch (Exception)
{
// ! ,
// , id ?
return null ;
}
}
* This source code was highlighted with Source Code Highlighter .
関数が例外をキャッチして呼び出し元のコードにスローしない場合があります。 最高レベルの関数である可能性があり、呼び出しコードはそうでない可能性があります。 他の場合、エラーが発生した後、関数は独立して回復を試みることがありますが、最終的に、この試みが失敗した場合、サムライの原則に従うこと以外の選択肢はありません。
--------------
（*）メタファーの種類の詳細については、関連する注記を参照してください： 「技術債務」および「第2システムの効果」 。
（**）「サムライの原理」に関する記事のほとんどは、真のサムライのような方法は仕事をするか死ぬかのいずれかであるという契約の第2部についてのみ述べています。 しかし、呼び出しコードは、サムライのチーフまたは彼の皇帝ではなく、サムライは疑いなく従わなければなりません。 aは、機能と同様に、「名誉のコード」に反するタスクを実行すべきではありません。 関数と呼び出しコードの関係では、両当事者が契約を遵守することが重要です。
（***）muraの原理は、ソフトウェア開発の革命ではありません。 原則はこれに長い間従いましたが、一部は契約による設計の助けを借りてかなり正式な方法でそれを行います。 前提条件と事後条件の概念を知りたい場合は、「コードを書かない方法」という記事から始めるか、契約設計のトピックに関する一連の記事を参照してください。