[erlang-questions] Suggestion for the Mnesia manual

Kostis Sagonas <>
Mon May 5 08:48:03 CEST 2008

Philip Robinson wrote:
> I am a big fan of putting the expected return value on every line that
> is otherwise used for side-effects.  Unification will then ensure that
> the code aborts on the first line in error; the later lines don't even
> get a chance to run.
> i.e.:
> init() ->
>     {atomic, ok} = mnesia:create_table(t1...),
>     {atomic, ok} = mnesia:create_table(t2...),
>     {atomic, ok} = mnesia:create_table(t2...).
> Even using anonymous vars helps, e.g.:
>     {ok, _} = some_side_effect_fun(),
> ensures that the return value wasn't {error, 'some message'} before continuing.

I am a very big fan of the practice that Philip advocates because it can 
avoid serious and often very subtle bugs in Erlang code.  In fact, in 
the latest dialyzer, the one in R12B-2, we have added a command-line 
option -Wunmatched_returns that warns for calls used for side-effects 
which ignore their return value. (The option is off by default.)

It strongly prefers code such as the above and will warn about calls 
which ignore their return value, such as:

  init() ->
      mnesia:create_table(t1, [{attributes,record_info(fields, foo)},
                               {disk_only_copies, [node()]} ]),
      mnesia:create_table(t2, [{attributes,record_info(fields, bar)},
                               {disk_only_copies, [node()]} ]),
      mnesia:create_table(t3, [{attributes,record_info(fields, baz)},
                               {disk_only_copies, [node()]} ]).

or for code which exists all over the place, even in standard libraries, 
such as the one below (from escript.erl):

  compile(Parse, Args) ->
      case compile:forms(Parse, [report]) of
          {ok,Module,BeamCode} ->
              erlang:load_module(Module, BeamCode),
              run_code(Module, Args);
          _Other ->
              fatal("There were compilation errors.")

which makes implicit assumptions (e.g. that the load always succeeds) 
that might not always hold.


More information about the erlang-questions mailing list