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

时间:2011-07-25 17:48:25

标签: erlang

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

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

或者假设我的功能包括来电io:function("Yada yada")。它应该返回ok还是什么都没有?

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

谢谢,

LRP

3 个答案:

答案 0 :(得分:24)

这是一种风格问题,但做出合理的选择对于使代码更具可读性和可维护性还有很长的路要走。以下是基于我自己的偏好以及我在标准库中看到的一些想法:

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

答案 1 :(得分:5)

  

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

如果根本不存在错误,或者任何错误表示编程错误,N。如果可能有充分理由失败,请返回{ok, N}(如果失败则返回{error, Reason}。)

  

它应该返回确定还是什么都没有?

在Erlang中,根本无法返回任何内容。如果您没有有意义的回报值,ok会很好。

答案 2 :(得分:2)

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