何时“让它崩溃”什么时候保护Erlang的代码？ [英] When to "let it crash" and when to defend the code in Erlang?

问题描述

所以，让它崩溃咒语Erlang代码是为了抵御残酷的世界事件，如意外拉动插头，硬件故障和不稳定的网络连接。

另一方面，防御性编程。

新的Erlang，我想知道，如何知道什么时候我想要的过程只是崩溃，当我想要保护流程与如果， case..of ，键入守卫？

说，我有一个身份验证模块，如果验证成功，可以返回 true / false result。如果由于登录/密码错误导致用户身份验证失败，是否只能成功实现场景并崩溃？

其他情况如何，如果在数据库或搜索结果是空的？

我想，我完全不能忽视防御性构造，因为任何守卫本质上都是捍卫正常流程应用程序？

有什么时候防御和何时崩溃？

解决方案

正如Fred Hebert在 http://ferd.ca/the -zen-of-erlang.html -

如果我知道如何处理错误，好的，我可以这样做为
具体错误。否则，只是让它崩溃！

我会说认证错误，空搜索结果等是预期的错误，那些这需要对用户的适当回应。

So, with "let it crash" mantra Erlang code is meant to be resistant to cruel world events like unexpected pulling the plug, hardware failure, and unstable network connections.

On the other hand, there is defensive programming.

Being new to Erlang, I wonder, how to know when I want the process just crash and when I want it to defend the flow with if, case..of, type guards?

Say, I have an authentication module, which can return true/false result if authenticated successfully or not. Should it just have successful scenario and crash if the user authentication fails due to wrong login/password?

What about other scenarios, like, if a product is not found in the database, or search results are empty?

I suppose, I can't ignore defensive constructs completely, as any guards are in their nature to defend the "normal" flow of the app?

Is there a rule of thumb when to defend and when to crash?

解决方案

As Fred Hebert says at http://ferd.ca/the-zen-of-erlang.html -

If I know how to handle an error, fine, I can do that for that specific error. Otherwise, just let it crash!

I'd say that authentication errors, empty search results, etc., are expected errors and those that warrant an appropriate response to the user.

这篇关于何时“让它崩溃”什么时候保护Erlang的代码？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！