为什么失败的快速样式程序比防御风格的程序短？

Question

我已经读到了诸如Erlang之类的语言中的失败方式编程风格最终如何比大多数其他语言中的防御风格更短的程序。对于所有类型的程序，这是正确的吗？

Answer 1

失败的程序不一定比防御风格的程序短：这取决于实施和使防御代码安全所需的措施。

在Erlang的情况下，由于声明性的样式以及VM如何确保为您生成错误案例，因此Fail-Fast程序通常更短。例如，在功能中：

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

传递给该函数的任何意外值都会导致一个错误可能被另一个过程捕获和处理的错误（即主管）。此类错误也不会危害整个系统，也不需要将代码添加到函数本身中 - 所有这些都通过预定的行为在正常执行路径之外完成。

在一种动态的语言中，失败不是常态，您必须手动检查边界并自己施加例外。然后，如果您不希望整个系统倒下，则必须在本地捕获异常（包括捕获量的顶级尝试...捕获）。错误处理代码通常必须在整个正常执行路径中插入。

在静态语言中，失败率不是常态，那么您的代码将在高度取决于您拥有的类型系统。如果该语言允许定义编译器最终为您检查边缘案例的类型，则通常不必在代码内部处理此类型具有这种类型系统的语言，在运行时会捕获许多错误，因此您不会有很多防御案例。

当无法避免处理错误时，支持失败习惯的语言（如erlang）将允许比不（是否静态）的语言更清晰的代码，主要是因为特殊情况的代码没有混合理想执行路径的代码。

Answer 2

参见乔·阿姆斯特朗（Joe Armstrong）的第4.3和4.4节 论文.

Answer 3

编程的失败风格集中在更好的代码可读性和调试上。用户体验是次要目标：用户可能会遇到奇怪的错误消息或程序故障，但是更高的代码质量使程序员可以轻松找到错误并纠正问题。

相反，防御风格的编程着重于用户和代码其他部分的验证输入。该代码更详细，因为程序员必须在错误的情况下仔细验证输入并优雅地失败。这导致了更多代码（从程序员的角度来看）和更健壮的应用程序（从用户的角度来看）。