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