私はしばしばErlang関数がok、または{ok, <some value>}、または{error, <some problem>}を返します。いつErlang関数が正常に戻りますか？
私の関数が整数Nを返すと仮定します。私の関数はただNを返しますか？{ok, N}？
または、私の機能には電話io:function("Yada yada")が含まれているとします。それはokを返しますか、まったく何も返しませんか？
または、私がレコードや楽しいことをしているとします。 {ok, R}または(ok, F}を返す必要がありますか？
おかげで、
LRP
これはスタイルの問題ですが、合理的な選択をすることは、コードをより読みやすく保守しやすくするための道のりです。ここではいくつかの私自身の好みに基づいた思考と私は標準ライブラリに表示されている。
{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です。と仮定し、私の関数が返す整数N.万一私の関数の戻り値だけN、または{OK、N}？
エラーの可能性が全くないか、エラーがプログラミングエラーの場合は、Nです。失敗する必要がある場合は、{ok, N}（および失敗の場合は{error, Reason}）を返します。
戻っても何も返されませんか？
Erlangでは、はは何も返しません。意味のある戻り値がない場合、okは問題ありません。
これは私が多くのアチームで自分を見つけることです。親指のルール（少なくとも私の親指）は、関数が主に他の関数（map（）、filter（）などの高次関数）で使用される場合、または関数が「純粋に」なるように設計されている場合、 （副作用がない）場合は、{ok、_}を返さずに結果を返すことを好むでしょう。この場合のエラーは、修正すべき論理的/アルゴリズム的なエラーのためでなければならず、関数のクライアントはそのようなエラーを認識する必要があります。
これはなぜdownvotedされた何らかの理由は？ –
おそらく答えは少し広がっているかもしれません - あなたが行っている方向が気に入っていると思いますが、あなたが何を意味しているのかを新人に伝えるためには、 "関数が* composable *と* pure * - >が' ok'を返さないならば、 'ok'か' {ok、Result} 'を返すべきで、それはコードですいずれにせよ、これは確かに多くの場合に有用な概念です。 – zxq9
私が作っておきたいことは、ユーザがエラーを処理できることが意味を持つならば、 '{error、Reason}'だけを返すべきことです。回復不可能なエラーの場合は、例外としてスローされる方がよい。 –
'リスト：nth/1'は、そのような良い例ではありません。なぜなら、それは（ユーザーが処理できるはずの）失敗のケースを持っているからです。 –
これは有効な例です。 'lists：nth/2'は無効な入力が与えられた場合にのみ失敗します。 'math：cos（foo）'も同じように失敗します。どちらも回復不可能なため、例外がスローされます。私がそれを記述したパターンは、回復可能なエラーだけを参照しています（Adamのコメントを参照）。 –