[erlang-questions] Exceptions vs Tagged Values (was Package Support/Use)

[Samuel Rivas]

Robert Virding wrote:
> Having everything as an exception is just as stupid and difficult to 
> manage as having nothing as an exception! Irrespective if you define the 
> exceptions as part of the documentation of a function, it is not a 
> documentation problem as such.
> 
> Save exceptions for things which are truly exceptional or program errors 
> or where things have gone wrong.
> 
> If the arguments to file:open have the wrong format or are wrong then it 
> is a program error and should be signalled with an exception, if the 
> file does not exist then it is application dependant whether it is an 
> exception or an accepted return. If I signal both as an exception then I 
> will always have to be able to handle the exception case which will 
> realy complicate the programmers job.

You only have to handle the exception case if you need it.  You can
try-catch matching with enoent exception ignoring any other exception if
you want.  With tagged values you have to add an extra case to propagate
the errors you do not handle.

try file:open("foo.txt") of
  Descriptor ->
    do_something(Descriptor)
  catch
    enoent ->
      do_another_thing()
  end
end

Versus

case file:open("foo.txt") of
  {ok, Descriptor} ->
     do_something(Descriptor);
  {error, enoent} ->
     do_another_thing();
  {error, Reason} ->
     {error, Reason}
end.
  
 
> "Let's see which exceptions signaled a file which wasn't there? Ah, 
> these 5 exceptions handle that case. I know I will write a new library 
> function which handles these cases for me which will make my life easier."

  But that is a problem of error handling. How do tagged values improve
it?  You also have to know which values signal which errors.

> Perhaps we should have used {yes,Value}|{no,Reason} instead of the more 
> loaded ok/error?
> 
> I have been known to have rather dogmatic views sometimes (often) but 
> soem commonsense is needed.

I find tagged-values to be against common sense, though.  Maybe we
look at them as the natural way because they have been there for a long
time, but they are inconvenient IMO.  Think about file:open type:

  "It is a function that receives a file name and returns a tuple.  The 
   first element of the tuple is either ok, or error.  If the first 
   element is ok, the second element is a file descriptor.  Otherwise,
   the second element is a term() indicating an error".  

Whereas the expected type should be :

  "It is a function that receives a file name and returns a file
   descriptor (DOT)".

So, I am changing the problem of "what is an exception?" by "is the
function type clear and simple?".  If you prefer the first type for
file:open, then eof, enoent, etc. are not exceptions.  However, I'd
rather have the second data type; it is less astonishing.

For what you call "program errors", there is another exception level:
errors.  With try-catch you can distinguish between throws (exceptions),
exits, and errors.  Now the problem is learning to use each of them in
the right situation, but this is another matter.

Regards.
-- 
	Samuel