Erlang 函数什么时候应该返回 ok？答案

【问题标题】：When should an Erlang function return ok?Erlang 函数什么时候应该返回 ok？
【发布时间】：2012-10-26 23:33:48
【问题描述】：

我经常看到 Erlang 函数返回ok，或{ok, <some value>}，或{error, <some problem>}。

假设我的函数返回一个整数 N。我的函数应该只返回 N 还是 {ok, N}？

或者假设我的函数包括调用io:function("Yada yada")。它应该返回ok 还是什么都不返回？

或者假设我正在制作唱片或乐趣。我应该返回{ok, R} 还是(ok, F}？

谢谢，

LRP

【问题讨论】：

标签： erlang

【解决方案1】：

这是一个风格问题，但做出合理的选择对于使您的代码更具可读性和可维护性大有帮助。以下是基于我自己的喜好和我在标准库中看到的一些想法：

如果函数可以返回成功和可恢复的失败案例，您可能希望成功案例看起来像{ok, _} 或ok。很好的例子是：orddict:find/2 和 application:start/1。我们这样做是为了在调用时可以轻松地对两种情况进行模式匹配。
如果函数只有一个成功案例和有意义的结果，那么只返回结果，因为不需要添加额外的信息。实际上，如果您要将结果包装在一个元组中，那么您就不能轻松地将调用链接在一起，例如如果bar/1 返回{ok, _}，foo(bar(N)) 可能不起作用。很好的例子是：lists:nth/2 和 math:cos/1。
如果函数只有一个成功案例而没有有意义的结果，常见的习惯用法是返回ok 或true，而不是函数中的最后一个返回值。很好的例子是：ets:delete/1 和 io:format/1。

【讨论】：

我想补充一点的是，如果用户能够处理错误是有意义的，你应该只返回{error, Reason}。如果是不可恢复的错误，最好作为异常抛出。
lists:nth/1 并不是一个很好的例子，因为它确实有一个失败案例（用户应该能够处理）。
这是一个有效的例子，因为lists:nth/2 只有在输入无效时才会失败。 math:cos(foo) 将以同样的方式失败。两者都是不可恢复的，因此会引发异常。正如我所描述的，该模式仅指可恢复的错误（请参阅 Adam 的评论）。

【解决方案2】：

假设我的函数返回一个整数 N。我的函数应该只返回 N 还是 {ok, N}？

如果根本不可能出错，或者任何错误都表示编程错误，N。如果有充分的理由失败，请返回 {ok, N}（如果失败，则返回 {error, Reason}）。

它应该返回 ok 还是什么都不返回？

在 Erlang 中，你不能什么都不返回。如果您没有有意义的返回值，ok 就可以了。

【讨论】：

【解决方案3】：

这是我经常遇到的一个难题。经验法则（至少我的拇指）是，如果一个函数主要与其他函数（高阶函数，如 map()、filter() 等）一起使用，或者该函数被设计为“纯粹的”功能性（无副作用），那么我宁愿不返回 {ok, _} 并简单地返回结果。这种情况下的错误必须是由于一些逻辑/算法错误而应该修复的，并且应该让函数的客户端知道任何此类错误。

【讨论】：

也许答案可以进一步扩展——我喜欢你前进的方向，并认为我理解你的意思，但也许需要更多的工作来表达新人你的意思。也许提供一个逻辑条件，例如：“如果函数是 composable 和 pure -> 不返回 ok；否则它应该总是返回 ok 或 @987654323 @"，也许可以在代码中说明这一点。无论如何，这在很多情况下确实是一个有用的概念。