[erlang-questions] Exceptions vs Tagged Values

[Mats Cronqvist]

Robert Virding wrote:
> What I was protesting against was the dogmatic :-) view that all library 
> functions should always generate exceptions. Which is as wrong as saying that
>  never should.

   a little dogmatism never killed anyone... well i guess it did actually. so
maybe i should de-dogmatize a little;

   the OTP libraries (and most other code too) rely entirely too much on tagged
tuples, and should throw much more often.

   e.g. file:open/2, which as far as i can tell, never throws.
file:open(blurg,rad) -> {error,einval}

   the question of when to throw and when to return {error,R} can of course be
discussed ad infinitum(*).

Robert Virding also wrote (about functions that always throws):
> To [differentiate between different types of error/exceptions] I have to keep
> track of the error reasons so I can differentiate between them and get the
> right handling. N.B. this has to be done in both directions. It is worse for
> the documentation as I have to document ALL the different error values to be
> able to do this separation.

   well, often you do want to keep track of the error reasons. perhaps the 
function author doesn't have the same opinion as you about what is "exceptional".
   in any case, i fully expect the author of a library function to "document ALL 
the different error values". seems you are suggesting that this is optional if 
you're returning {error,R}, but mandatory if you're throwing R.

   mats

(*) for file:open/2 in particular, i see no reason for it to do anything but
throw or return the fd. if the file should be there, that's what you want; if 
you don't know if the file exists/is readable, you should call read_file_info/1 
first.

x([File|Fs],Fun,Acc) ->
   case file:read_file_info(File) of
     {ok,#file_info{access=read}} -> x(Fs,Fun,[Fun(file:open(File,[read]))|Acc]);
     _ -> x(Fs,Fun,Acc)
   end.

   file:read_file_info/1 btw should (imo) never throw :>

   to whom it may concern; i know this is not proper erlang code. it's blub, so
give it a rest.