在 Erlang 中返回错误代码
我正在编写一些 Erlang 代码，我非常不确定是否应该让一切快速失败。我发现快速失败的一个问题是，对于开发人员/用户来说，生成的异常毫无意义。知道我应该返回什么，这不会给出深奥且难以阅读的堆栈跟踪吗？
I'm writing some Erlang code and I'm very unsure whether I should let everything fail fast. One problem I find with fail fast is that for the developer/user the exception generated is pretty meaningless. Any idea what I should return which would not give esoteric and hard to read stack traces?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我建议您使用 error_logger(3) 进行日志记录，并让开发人员查看幕后实际发生的情况。建议遵循 OTP 原则，以便收集由进程崩溃时的虚拟机。
I'd recommend you logging with error_logger(3) and have developer look what actually happens behind the scenes. It's recommended to follow OTP principles in order to collect all data which is returned by VM when process crashes.
我建议快速失败并学习如何读取堆栈跟踪。
I would advise to fail fast and learn how to read stack traces.
Erlang 的基本原理是：
我发现避免所谓的防御性编程非常有用。这个概念在 Erlang 编程规则页面中有更详细的解释：
http:// www.erlang.se/doc/programming_rules.shtml#HDR11
此外，即使一些 Erlang 错误可能有点神秘，一个很好的处理方法是跟踪它们！ Erlang 中的跟踪非常简单。看看这个快速参考：
http://aloiroberto.wordpress .com/2009/02/23/tracing-erlang-functions/
或者直接参考官方文档。
The basic principle in Erlang is:
I found quite useful to avoid the so called defensive programming. The concept is explained in a bit more detail in the Erlang Programming Rules page:
http://www.erlang.se/doc/programming_rules.shtml#HDR11
Moreover, even if some of the Erlang errors can be a bit cryptic, a nice way to deal with is trace them! Tracing in Erlang is pretty simple. Have a look to this quick reference:
http://aloiroberto.wordpress.com/2009/02/23/tracing-erlang-functions/
or simply refer to the official documentation.
由于 Erlang 是一种函数式语言，如果您倾向于编写纯函数，那么通常很容易发现错误，因为给定一个参数的纯函数将始终返回相同的结果。因此，通过堆栈跟踪，一旦找到失败的函数，您就可以找出导致错误的原因。与命令式编程相反，您不需要花费大量时间来调试代码，通常您甚至不需要调试器，并且搜索错误变成了一个有趣的游戏。 这篇文章很有用。
Since Erlang is a functional language errors are often easily spot if you tend to write Pure functions, because pure function given one arguments will always return the same result. Thus, having the stack trace, once you found the failed function you can figure out what caused an error. Opposed to imperative programming you don't need to spend a lot of time debugging your code, often you don't even need the debugger, and searching the error turns to an interesting game. This article is useful.