<ol><li>I tend to use exit/1 when my semantics are 'this process is done running, nothing more to do here'. </li><li>I use 'error/1' when the semantics are 'there is likely an error in code that will require some programmer to change what they do'.</li>
<li>'throw/1' is usually something I use in a module-local manner for non-local returns for exceptions I expect to handle in-module.</li><li>I use {error, Something} when I need to express some exceptional-but-not-deadly case to the user, something they might know how to handle and fix, or a boundary condition that they might expect. It's not deadly or game changing, but it's not a normal result either,</li>
</ol><div>That's the general way I picked after researching exceptions and their meaning when writing Learn You Some Erlang. Different people who worked on Erlang seem to disagree on the semantics of throw vs. error (although they seemed to agree on exits), so it's just not exactly simple.<br>
</div><div><br></div><div class="gmail_quote">On Tue, Nov 15, 2011 at 12:07 PM, David Mercer <span dir="ltr"><<a href="mailto:dmercer@gmail.com">dmercer@gmail.com</a>></span> wrote:<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Why is your second alternative (viz., “f(X) -> Y | exit(..)”) not the default preferred option for all Erlang code? It seems to express your meaning and intent better than a tuple return code. You can always wrap it in a try if you want to catch the error.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Me, I always have trouble deciding between exit(…) and error(…).</span></p><p class="MsoNormal">
<span style="font-size:11.0pt;color:#1F497D"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Cheers,</span></p><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p><p class="MsoNormal">
<span style="font-size:11.0pt;color:#1F497D">DBM</span></p><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> <a href="mailto:erlang-questions-bounces@erlang.org" target="_blank">erlang-questions-bounces@erlang.org</a> [mailto:<a href="mailto:erlang-questions-bounces@erlang.org" target="_blank">erlang-questions-bounces@erlang.org</a>] <b>On Behalf Of </b>Joe Armstrong</span></p>
<div><b>Sent:</b> Monday, November 14, 2011 5:25 AM</div><div><b>To:</b> Steve Davis</div><div><b>Cc:</b> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a></div><div><b>Subject:</b> Re: [erlang-questions] When to return {ok, Value} or just the Value</div>
</div></div><div><div class="h5"><p class="MsoNormal"> </p><p class="MsoNormal" style="margin-bottom:12.0pt">You have several alternatives<div><br></div><div> f(X) -> Y uses if you know computing f(X) always returns Y for all X</div>
<div><br></div><div> f(X) -> Y | exit(..) if "most" values of f(X) are valid and you could not take care of the</div><div> error case in the caller</div><div><br>
</div>
<div> f(X) -> {ok, Y} | {error, Z} if some values of X cause f(X) to fail and you want to take care</div><div> of the error in the caller.</div><div><br></div><div>
returning {ok, Y} | {error,Z} is a strong signal to the person reading the code that the caller will</div><div> do something with *both* return values.</div><div><br></div><div> The caller might just write {ok,Val} = f(X) and not handle the error case, but the reader of the</div>
<div>code will think - "ahh something might go wrong, and this code may need to be fixed later."</div><div>it's not just what you write but what will be inferred by the reader.</div><div><br></div><div> Code using {ok, Val} | {error, Why} tends to lead to messy cascades of nested cases, so the</div>
<div> Y | exit(...) code style looks prettier.</div><div><br></div><div> The entire picture gets complicated sing catch/throw/try etc. so there is no "right" answer.</div><div><br></div><div> I guess you should choose be locally consistent in your code - choose a convention and stick to it</div>
<div>in your code and chose the variant that will be easiest to read and maintain. If you end up with</div><div>loads of nested cases/trys you might have chosen the wrong convention.</div><div><br></div><div>Cheers</div>
<div>
<br></div><div>/Joe</div><div> <br></div><div><br></div><div><br><br></div><div><p class="MsoNormal">On Sun, Nov 13, 2011 at 1:35 AM, Steve Davis <<a href="mailto:steven.charles.davis@gmail.com" target="_blank">steven.charles.davis@gmail.com</a>> wrote:</p>
<p class="MsoNormal">Is there a rule-of-thumb guidance as to when it is the right "time" to<div>return {ok, Value} and when to return just the raw value.</div><div><br></div><div>Both are valid approaches according to the coding guidelines. The</div>
<div>libraries do both.</div><div><br></div><div>All and any comments/observations appreciated.</div><div><br></div><div>best,</div><div>/s</div><div>_______________________________________________</div><div>erlang-questions mailing list</div>
<div><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a></div><div><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a></div>
</p></div><p class="MsoNormal"> </p></p></div></div></div></div></div><div>_______________________________________________</div><div>
erlang-questions mailing list</div><div>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a></div><div>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a></div><div>
<br></div><div><br></div></blockquote></div><div><br></div>