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

Question

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

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

或者假设我的功能包括调用io:function("Yada yada") 。 它应该ok还是什么都没有？

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

谢谢，

LRP

Answer 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 。

Answer 2

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

如果根本不存在错误，或者任何错误表示编程错误，则为N 如果可能有理由失败，请返回{ok, N} （以及{error, Reason}以防失败）。

它应该还原还是什么都没有？

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

Answer 3

这是我在很多时候发现自己的难题。 拇指的规则（至少我的拇指）是，如果一个函数主要用于其他函数（更高阶函数，如map（），filter（）等...）或者该函数被设计为“纯粹”功能性（没有副作用），然后我宁愿不返回{ok，_}并简单地返回结果。 在这种情况下的错误必须是由于某些逻辑/算法错误应该被修复，并且该函数的客户端应该知道任何这样的错误。