global_name_server question.

[Peter Olin]

Claes Wikstrom wrote:
> This is really irritating that io:format/2 doesn't
> fail when presented with unformatable data.
> It simply fails to write anything and returns
> an error code.

True! Really irritating. And of course the source of many obscure run-time errors that are not spotted right away as
they happen.

> A very good practice is to start to write
> ok = io:format(.....

> everywhere in the code, the match then works as an
> assertion and the process will crash when io:format/2
> returns an error code.

A "very good practice" is perhaps exaggerating the positive side of it a bit. I would say it is a necessary,kludgy
workaround enforced by poor design in the library modules. And we have lived with it too long already.

There are many places in OTP where errors are "signalled" this way. 

The practice of *returning* {error,}-tuples and {ok,}-tuples instead of simply returning the relevant values, or EXITing
also makes it impossible to have nested function calls. 

For instance: (code not compiled or executed)
copy1(File1, File2) ->
    file:write_file("dot_login", file:read_file(".login")).

is impossible. Instead one has to write:

copy2(File1, File2) ->
   {ok, B} = file:read_file(".login"),
    ok = file:write_file("dot_login", B).

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. 


"Backwards compatibility" has been the often mentioned reason for keeping a lot of the inconsistencies in the OTP
libraries, but I really don't think that's an argument.

What's the "public opinion" on revising and rewriting interfaces so that functions have some consistent use of "types",
return values, EXIT reasons, etc.? There are many ways of keeping the system backwards compatible, without actively
preventing improvements where there is a need for them. (New names for revised modules, forwarding of calls, compiler
warnings, etc)




-- 

/Peter Olin (mailto:peter.olin@REDACTED)