契約による設計と防御的プログラミングは、ある意味で互いに逆です。DbCでは、コラボレーター間のコントラクトを定義し、コラボレーターがそのコントラクトを尊重するという前提の下でプログラミングします。防御的プログラミングでは、協力者violateの契約を前提としてプログラミングします。
DbCスタイルで記述された実際の平方根ルーチンは、負の数を渡すことが許可されていないことを契約に明記し、負の数に遭遇することは決してないと想定します。防御的に書かれた実際の平方根ルーチンは、負の数が渡されたと想定し、適切な予防策を講じます。
注：もちろん、DbCでは他の誰かが契約をチェックする可能性があります。たとえば、エッフェルでは、契約システムは実行時に負の数をチェックし、適切な例外をスローします。 Spec＃では、定理の証明者は、ルーチンが負の数を渡されないことを証明できない場合、コンパイル時に負の数をチェックし、ビルドを失敗させます。違いはプログラマはこのチェックを行わないということです。
契約による設計（DbC）は、防御的にプログラミングするための方法ですか？
はい。
「防御的プログラミング」は、多くの場合、時間を無駄にする言い訳になります。通常の例外の原因となるもののチェックに時間を浪費することがよくあります。例外の代わりに、例外処理句の代わりに追加のIFステートメントが書き込まれます。
契約を定義し、それで完了します。
誰かが契約に違反すると、プログラムは-通常のイベントの過程で-正常に処理できる通常の例外を解除して発生させます。
「防御プログラミング」と「エラー防止」は、エラーを防止するのではなく、エラーを追加するように表示できます（エラー防止チェック自体が誤っているため）。
例外処理は、「防御的プログラミング」よりもはるかに優れた例外の抑制、ログ記録、処理を行うことができます。