erlang - フェイルファストスタイルのプログラムがディフェンシブスタイルのプログラムよりも短いのはなぜですか？

Question

Erlangのような言語でのフェイルファストスタイルのプログラミングが、他のほとんどの言語で見られる防御スタイルよりもはるかに短いプログラムになる方法について読んだことがあります。これはすべてのタイプのプログラムに対して正しいですか、そしてこれの理由は何ですか？

Answer 1

フェイルファストプログラムは、必ずしも防御スタイルのプログラムよりも短いわけではありません。それは、防御コードを安全にするために必要な実装と対策によって異なります。

Erlangの場合、宣言型のスタイルとVMがエラーケースを確実に生成する方法のために、通常、フェイルファストプログラムは短くなります。例として、関数では：

day(1) -> sunday;
day(2) -> monday;
day(3) -> tuesday;
day(4) -> wednesday;
day(5) -> thursday;
day(6) -> friday;
day(7) -> saturday;

関数に予期しない値が渡されると、別のプロセス（つまり、スーパーバイザー）がキャッチして処理できるエラーが発生します。このようなエラーは、システム全体を危険にさらすことはなく、関数自体にコードを追加する必要もありません。これらはすべて、事前に定義された動作によって通常の実行パスの外部で実行されます。

フェイルファストが標準ではない動的言語では、境界を手動でチェックし、自分で例外をスローする必要があります。次に、システム全体を停止させたくない場合は、例外をローカルでキャッチする必要があります（トップレベルのtry ... catchsが含まれます）。エラー処理コードは通常、通常の実行パス全体に挿入する必要があります。

フェイルファストが標準ではない静的言語では、コードの長さは、使用している型システムに大きく依存します。言語でエッジケースがコンパイラによってチェックされるタイプを定義できる場合、通常、非決定的なイベント（ファイルが機能しない、予期しないユーザー入力など）の外で、コード内でこれを処理する必要はありません。このような型システムを使用する言語では、実行前に多くのエラーがキャッチされるため、防御的なケースはそれほど多くありません。

エラー処理を回避できない場合、フェイルファストイディオムをサポートする言語（Erlangなど）は、サポートしない言語（静的かどうかに関係なく）よりも間違いなく明確なコードを許可します。これは主に、特殊なケースのコードが理想的な実行パスのコード。

Answer 2

ジョーアームストロングの論文のセクション4.3と4.4を参照してください。

Answer 3

フェイルファストスタイルのプログラミングは、コードの可読性とデバッグの向上に重点を置いています。ユーザーエクスペリエンスは二次的な目標です。ユーザーは奇妙なエラーメッセージやプログラムの失敗を経験する可能性がありますが、コードの品質が高いため、プログラマーはバグを簡単に見つけて問題を修正できます。

代わりに、防御的なスタイルのプログラミングは、ユーザーおよびコードの他の部分からの検証入力に焦点を合わせています。プログラマーは入力を注意深く検証し、エラーが発生した場合は正常に失敗する必要があるため、コードはより冗長になります。これにより、（プログラマーの観点から）より多くのコードと（ユーザーの観点から）より堅牢なアプリケーションが実現します。