[erlang-questions] Exceptions vs Tagged Values

[Richard A. O'Keefe]

Mats Cronqvist <mats.cronqvist@REDACTED> wrote:
	the OTP libraries (and most other code too) rely entirely too much on tagged
	tuples, and should throw much more often.
	
Now we have agreement!

	(*) 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.
	
The fact that read_file_info/1 succeeds and says the file is accessible
does NOT guarantee that you will be able to open the file.
Some possible reasons:

 - you may have reached the limit of some system or Erlang run-time
   resource required by open files but not required by read_file_info/1.
   (For example, in C+POSIX, access() doesn't require a file descriptor,
   but open() does.)

 - the world is concurrent.  Between the return from read_file_info/1
   and the call to the file opening function, the process may be suspended
   (by Erlang or the operating system) and some other (Erlang or operating
   system) process may alter the file system.  The fact that this is rare
   doesn't mean it won't happen, it just means that it will happen to
   customers instead of during your own tests.

I have faced this problem in C and in implementing I/O support for Prolog.
The *only* way to be sure that opening a file will work is to try to open
the file.  Nothing else tells you *exactly* what you need to know.

What's really needed is a set of design principles which will enable
programmers to *predict* whether a library function will throw or return
a tagged tuple without having to remember.

For Quintus Prolog, we managed that.  I was able to classify exceptions
into 16 classes.  (Quintus "simplified" that be fusing my "error" classes
with my "failure" classes; I still think that was a mistake, but the
distinction wouldn't be useful for Erlang.)

I'm on a mailing list for the revision of the Prolog standard; just last
week there was a proposal to add some new built-in predicates, and a question
about what errors should be detected.  The answer was unanimuous, which was a
very pleasant outcome.  What's more, there seemed to be agreement about the
_reasons_ for the decision.  So at least at the level of something like
the 'lists' module, it can be done.