[erlang-questions] Package Support/Use

Ulf Wiger (TN/EAB) ulf.wiger@REDACTED
Mon Nov 6 11:30:49 CET 2006

Christian S wrote:
> > > only a closet C programmer would use that idiom.
> How are tagged tuples bad? How do one reason for such an opinion?
> I share the despise for C programming nowdays, but there I 
> learned to love sprinkling assert() sanity checks all over 
> the code. They caught so many errors that I thought were impossible.
> I find that tagged tuples does much of the same for me in Erlang.
> Crash as soon as possible when code derails off what I 
> intended it to do. Nor do I find this to exclude the use of 
> throwing exceptions.

With tagged return values, you either use case statements to check
whether the call worked. To use my favourite example:

case timer:send_after(Time, timeout) of
    {ok, TimerRef} ->
        %% continue happily
    {error, Reason} ->
        %% ...!? A free beer at the EUC to anyone who can
        %% figure out a useful alternative to crashing.

or use assertions:

{ok, TimerRef} = timer:send_after(Time, timeout),

The problem with the latter is that if your function contains several of
those constructs, say:

read_data() ->
   {ok, Bin_a} = file:read_file("a"),
   {ok, Bin_b} = file:read_file("b"),
   {ok, Bin_c} = file:read_file("c"),
   [Bin_a, Bin_b, Bin_c].

and you get an exit with {badmatch, {error, enoent}}, you're lost
regarding what particular line caused the error, unless the Reason part
is unique for all constructs.

On the other hand, if the called function exits, like:

2> erlang:start_timer(a,self(),timeout).

=ERROR REPORT==== 6-Nov-2006::11:29:22 ===
Error in process <0.40.0> with exit value:

** exited: {badarg,[{erlang,start_timer,[a,<0.40.0>,timeout]},
                    {shell,eval_loop,3}]} **

and the exit message reports the actual arguments passed to the crashed
function, I'm much better off.

Ulf W

More information about the erlang-questions mailing list