erlang 为什么快速失败型项目比防御型项目要短?

lstz6jyr  于 2022-12-16  发布在  Erlang
关注(0)|答案(3)|浏览(201)

我曾经读过关于Erlang这样的语言中的快速失败编程风格是如何比大多数其他语言中的防御性编程风格产生更短的程序的。这对所有类型的程序都是正确的吗?原因是什么?

7jmck4yq

7jmck4yq1#

快速失效程序不一定比防御型程序短:这取决于实现和使防御代码安全所需的措施。
在Erlang的情况下,由于声明式的风格以及VM如何确保为您生成错误用例,故障快速程序通常会更短。

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

传递给函数的任何意外值都会导致错误,该错误可由另一个进程捕获和处理(即:这样的错误也永远不会危及整个系统,并且不需要向函数本身添加代码--这都是在正常执行路径之外通过预定行为完成的。
在一个动态语言中,故障快速不是标准,你必须手动检查边界并自己抛出一个异常。然后,如果你不想让整个系统崩溃,你必须在本地捕获异常(包括顶级的try... catch)。错误处理代码通常必须插入整个正常的执行路径。
在一个静态语言中,故障快速不是标准,那么你的代码长度将在很大程度上取决于你所拥有的类型系统。如果语言允许定义类型,编译器最终会为你检查边缘情况,那么你通常不必在代码内部,在不确定事件之外处理这个问题(文件不工作,意外的用户输入,等等)在使用这种类型系统的语言中,许多错误将在运行时之前被捕获,因此您不会有那么多防御性的情况。
当错误处理不可避免时,支持故障快速处理习惯用法的语言(如Erlang)将比不支持(静态或非静态)习惯用法的语言允许更清晰的代码,这主要是因为特殊情况的代码不会与理想执行路径的代码混合在一起。

dgsult0t

dgsult0t2#

参见Joe Armstrong的thesis的第4.3节和第4.4节。

s71maibg

s71maibg3#

快速编程风格的重点是更好的代码可读性和调试。用户体验是次要目标:用户可能会遇到奇怪的错误消息或程序故障,但是代码的更高质量允许程序员容易地发现错误并纠正问题。
相反,防御型编程关注于验证来自用户和其他代码部分的输入。代码更冗长,因为程序员必须仔细验证输入,并在出现错误时优雅地失败。这导致更多的代码(从程序员的Angular 来看)和更健壮的应用程序(从用户的Angular 来看)。

相关问题