Fail Fast Styleプログラムが防御スタイルプログラムよりも短いのはなぜですか？

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;

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

Fail-Fastが標準ではない動的な言語では、境界を手動でチェックし、自分で例外を投げる必要があります。次に、システム全体をダウンしたくない場合は、ローカルで例外をキャッチする必要があります（トップレベルの試み...キャッチが含まれています）。通常、エラー処理コードは、通常の実行パス全体に挿入する必要があります。

Fail-Fastが標準ではない静的言語では、コードがどれくらいの期間であるかは、持っているタイプシステムに大きく依存します。言語がコンパイラによってエッジケースが最終的にチェックされているタイプを定義できる場合、通常、コード内でこれを処理する必要はありません。このようなタイプシステムを備えた言語では、ランタイム前に多くのエラーがキャッチされるため、防御的なケースはそれほど多くありません。

エラー処理を避けられない場合、フェイルファストイディオム（erlangなど）をサポートする言語は、特別なケースのコードが混合されていないため、言語よりも間違いなく明確なコードを可能にします（静的かどうか）。理想的な実行パスのコード。

Answer 2

Joe Armstrongのセクション4.3および4.4を参照してください 定説.

Answer 3

プログラミングのフェイルファストスタイルは、コードの読みやすさとデバッグの向上に焦点を当てています。ユーザーエクスペリエンスは二次ターゲットです。ユーザーは奇妙なエラーメッセージやプログラムの障害を経験する場合がありますが、コードの品質が大きくなると、プログラマーはバグを簡単に見つけて問題を修正できます。

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