[erlang-questions] Any wisdom to offer on "tagged return values"

Ulf Wiger ulf.wiger@REDACTED
Tue May 5 18:27:18 CEST 2009

Robert Virding wrote:
> Ah, well as you can understand I think that the advice is still good. 
> But not everywhere of course, in many cases generating an error the the 
> right thing to do.
> Robert

This is part of the problem, not easily solved.

Based on my experience from large projects, these recommendations
have a tendency to be either completely ignored or followed in
absurdum. In the case of tagging all return values, it tends
to be the latter, as most programmers feel very uncomfortable
with throwing exceptions.

(Large-project dynamics may even enforce this, in that if your
code "crashes", you have to contend with a formal trouble ticket,
but if it returns a cosy error tuple, you may not need to.)

The very sensible advice that "in some cases, not following the
guideline is the right thing to do" doesn't seem to work well
on a larger scale. For small teams with very good programmers,
it's a given.

I've seen a lot of code where practically all function calls
are coupled with a case statement in the form of

case f(...) of
   {ok, GoodResult} -> continue(GoodResult);
   {error, Reason}  -> {error, Reason}

When you've waded ten levels deep into constructs like these,
you begin to wonder who will ever consider the source and
content of the error tuple. It becomes a form of "hot potato"
programming. Everyone is a good citizen, but noone takes
responsibility for the error.

In the old days - 10 or so years ago - the exceptions raised
from failed pattern matching were much less helpful than
today. Back then, you really didn't have that much choice
in practice, if you wanted your code to be debuggable.
I think that particular reason for tagging return values
has largely gone away.

Also, functions that return tagged values don't compose well.
I've found that I don't use composition that much in my code,
and I think it's something that one can certainly go overboard
with. The problem that frequent case matching clutters up the
code is a bigger issue, IMHO.

At the end of the day, writing good guidelines is extremely
difficult, because good programming is so much about
aesthetics and good judgement. That's not easy to formalize.

Ulf W

> 2009/5/5 mats cronqvist <masse@REDACTED <mailto:masse@REDACTED>>
>     Robert Virding <rvirding@REDACTED <mailto:rvirding@REDACTED>> writes:
>      > Erlang has always had exceptions! The problem is much more complex
>      > than this.  Always signaling an error would make coding extremely
>      > difficult, almost as bad as always forcing you to check return
>     values.
>      Well, I don't agree. But that's neither here nor there. The original
>      question was re the official programming advice from OTP (which
>      states; "Use tagged return values."), and whether that advice is
>      (still) good.
>      mats
> ------------------------------------------------------------------------
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

Ulf Wiger
CTO, Erlang Training & Consulting Ltd

More information about the erlang-questions mailing list