[erlang-questions] When to return {ok, Value} or just the Value

[Fred Hebert]

   1. I tend to use exit/1 when my semantics are 'this process is done
   running, nothing more to do here'.
   2. 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'.
   3. 'throw/1' is usually something I use in a module-local manner for
   non-local returns for exceptions I expect to handle in-module.
   4. 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,

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.

On Tue, Nov 15, 2011 at 12:07 PM, David Mercer <dmercer@REDACTED> wrote:

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.
>
>
>
> Me, I always have trouble deciding between exit(…) and error(…).
>
>
>
> Cheers,
>
>
>
> DBM
>
>
>
> *From:* erlang-questions-bounces@REDACTED [mailto:
> erlang-questions-bounces@REDACTED] *On Behalf Of *Joe Armstrong
> *Sent:* Monday, November 14, 2011 5:25 AM
> *To:* Steve Davis
> *Cc:* erlang-questions@REDACTED
> *Subject:* Re: [erlang-questions] When to return {ok, Value} or just the
> Value
>
>
>
> You have several alternatives
>
>       f(X) -> Y                  uses if you know computing f(X) always
> returns Y for all X
>
>       f(X) -> Y | exit(..)     if "most" values of f(X) are valid and you
> could not take care of the
>                                      error case in the caller
>
>       f(X) -> {ok, Y} | {error, Z}   if some values of X cause f(X) to
> fail and you want to take care
>                                                 of the error in the caller.
>
>       returning {ok, Y} | {error,Z} is a strong signal to the person
> reading the code that the caller will
>       do something with *both* return values.
>
>       The caller might just write {ok,Val} = f(X) and not handle the error
> case, but the reader of the
> code will think - "ahh something might go wrong, and this code may need to
> be fixed later."
> it's not just what you write but what will be inferred by the reader.
>
>       Code using {ok, Val} | {error, Why} tends to lead to messy cascades
> of nested cases, so the
>       Y | exit(...) code style looks prettier.
>
>       The entire picture gets complicated sing catch/throw/try etc. so
> there is no "right" answer.
>
>       I guess you should choose be locally consistent in your code -
> choose a convention and stick to it
> in your code and chose the variant that will be easiest to read and
> maintain. If you end up with
> loads of nested cases/trys you might have chosen the wrong convention.
>
> Cheers
>
> /Joe
>
>
>
>
> On Sun, Nov 13, 2011 at 1:35 AM, Steve Davis <
> steven.charles.davis@REDACTED> wrote:
>
> Is there a rule-of-thumb guidance as to when it is the right "time" to
> return {ok, Value} and when to return just the raw value.
>
> Both are valid approaches according to the coding guidelines. The
> libraries do both.
>
> All and any comments/observations appreciated.
>
> best,
> /s
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111115/055dbbe4/attachment.htm>