[erlang-questions] Package Support/Use

[Robert Virding]

There are so many threads now in this discussion I will comment the last 
one. Couldn't we have a forum instead of a mailing list?

Today you have the possibility of having three types of returns from a 
(library) functions: yes it worked; no it didn't; and it crashed 
exceptionally. In most contexts they mean different things. If you 
remove the no option then the user who needs this will have to try to 
work this out by looking at the exceptions. Unless the the libraries are 
specificaly written with this in mind and extremely well documented then 
this will be well-nigh impossible to do. Why did I get this 'badarg', 
was it a "no" answer or were my arguments wrong?

In many cases you need to differentiate this. If file:open bombs it 
would be very nice to know if I couldn't open the file or if my 
arguments were wrong. That is not the same thing and handling them as 
such will not make users happy.

There will be written an aweful lot of wrapper functions to help you 
remember:

file_open(Name, Opts) ->
     try file:crashing_open(Name, Opts) of
	Pid -> {ok,Pid}
     catch
	error:not_found -> {error,not_found};
	error:permission -> {error,permission};

	<all other reasons why a file could not be opened/created>
     end.

Unfortunately I have to know, and remember, them all. User friendly.

In the dict library these cases are handled separately, there is 
dict:find which has a tagged return indicating if the value was found, 
and there is dict:fetch which assumes that it is there. The user uses 
the one which matches the requirements. It is then much easier to 
comprehend the true intentions rather than wrapping things in catch/try.

It actually reminds me of a very funny Monty Python sketch. A customer 
in a restaurant points out that his fork is dirty, everyone working in 
the restaurant gets very worked-up, pandamonium follows and it ends with 
the head chef committing suicide. Unfortunately I can't remember in 
which episode it was.

BUT THEN AGAIN - it would simplify writing many of the libraries. For 
example in io when scanning/parsing a file there would be no need to try 
and recover on an error to keep going - just BANG exception and let the 
some other process handle it. Epp detects an error - BANG exception. 
Hell we could do it for the compiler as well. Why go to all the trouble 
to keep track of errors and warnings and return something helpful? It 
detects an error - BANG exception and let the user handle it. Seeing we 
have removed the grey area between right and exception warnings have to 
go - BANG exception. The compiler would return ModuleName | 
{ModuleName,Bin} (untagged) depending on the arguments, and the 
exceptions {'EXIT',wrong} and {'EXIT',unused_variable}.

I can get on to it next week perhaps. Of course Björn would have put 
some work into optimising catch/try.

Robert