global_name_server question.
Claes Wikstrom
klacke@REDACTED
Fri Jun 4 23:34:01 CEST 1999
Craig Dickson" <crd@REDACTED> wrote:
>
> Peter Olin wrote:
>
> > Not only is this awkward, but also, instead of simply handling the values
> > we're interested in we need to match structures and explicitly force our
> > code to crash where it would be natural to have that behaviour implicitly.
>
> True. It isn't quite true, though, that nested function calls are
> impossible.
> There is another way to write it than your copy2:
>
> copy3(File1, File2) ->
> file:write_file("dot_login",
> begin {ok, B} = file:read_file(".login"), B end).
I think Peter has a point here, on the other hand if we had the
situation that all the library functions were to exit/1 on failure
I'm sure that Peter would be the first to tell us that this
idea of always calling exit/1 isn't that good either.
The question of whether to return {error, Reason} or to
call exit/1 simply isn't possible to answer.
Today the erlang libraries are almost consistent in
error return values with the {error, Reason} tuple.
The programmer can simulate an exit/1 behaviour by
adding match assertions in the code as in ok = io:format...
I do that often.
Nesting funtion calls isn't that easy though and I didn't like
the neither the proposed begin end thinge nor the Assert fun
This discussion is 10 years old, we've had this debate
for years and we've never even come close to consencus .
Perhaps we should have yet another API as in:
Fd = file:x_open(File, [read, raw]),
B = file:x_read(Fd, 2048),
and
io:x_format("Hello", []),
mnesia:x_transaction(Fun),
Which fails with exit/1 on error.
??
/klacke
More information about the erlang-questions
mailing list