<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'><br><hr id="zwchr"><blockquote id="DWT543" style="border-left:2px solid rgb(16, 16, 255);margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">You have several alternatives<br><br>      f(X) -> Y                  uses if you know computing f(X) always returns Y for all X<br><br>      f(X) -> Y | exit(..)     if "most" values of f(X) are valid and you could not take care of the<br>
                                     error case in the caller<br><br>      f(X) -> {ok, Y} | {error, Z}   if some values of X cause f(X) to fail and you want to take care<br>                                                of the error in the caller.<br>
<br>      returning {ok, Y} | {error,Z} is a strong signal to the person reading the code that the caller will<br>      do something with *both* return values.<br><br>      The caller might just write {ok,Val} = f(X) and not handle the error case, but the reader of the<br>
code will think - "ahh something might go wrong, and this code may need to be fixed later."<br>it's not just what you write but what will be inferred by the reader.<br><br>      Code using {ok, Val} | {error, Why} tends to lead to messy cascades of nested cases, so the<br>
      Y | exit(...) code style looks prettier.<br></blockquote><br>Actually, it might "look" prettier in the documentation but it is messier to use. It forces you to do a case to find out if the call worked as there is usually no safe way of checking the return value. I cannot just write {ok,Val} = f(X) to generate an error if it went wrong, but have to write:<br><br>case f(X) of<br>    {error,Reason} -> error(Reason);<br>    Val -> Val<br>end<br><br>to test if it went wrong. That is why I think lists:keyfind has bad return values, it only works neatly if you know the structure of the returned tuple, the general case becomes as above.<br><br>Otherwise as above. If the function always returns a value or crashes then don't wrap, else if can either return a success value or an exit reason then wrap.<br><br>Robert<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><br>      The entire picture gets complicated sing catch/throw/try etc. so there is no "right" answer.<br><br>      I guess you should choose be locally consistent in your code - choose a convention and stick to it<br>
in your code and chose the variant that will be easiest to read and maintain. If you end up with<br>loads of nested cases/trys you might have chosen the wrong convention.<br><br>Cheers<br><br>/Joe<br>                                          <br>
<br><br><br><div class="gmail_quote">On Sun, Nov 13, 2011 at 1:35 AM, Steve Davis <span dir="ltr"><<a href="mailto:steven.charles.davis@gmail.com" target="_blank">steven.charles.davis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Is there a rule-of-thumb guidance as to when it is the right "time" to<br>
return {ok, Value} and when to return just the raw value.<br>
<br>
Both are valid approaches according to the coding guidelines. The<br>
libraries do both.<br>
<br>
All and any comments/observations appreciated.<br>
<br>
best,<br>
/s<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br>
<br>_______________________________________________<br>erlang-questions mailing list<br>erlang-questions@erlang.org<br>http://erlang.org/mailman/listinfo/erlang-questions<br></blockquote><br></div></body></html>