[erlang-questions] Exceptions vs Tagged Values

[Richard A. O'Keefe]

I pointed out that 
	> 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.
and gave two explicit reasons why.

Ulf Wiger replied:	
	But in most cases, read_file_info() does tell you whether
	or not you can expect file:open() to work, given that some
	exceptional condition (e.g. out of file descriptors) does
	not happen, and that there isn't a race condition for the
	file (which could also be regarded as exceptional.
	
Why should we tolerate for a single instant an approach which
sort of works most of the time kind of if you don't have bad luck
when there is a 100% reliable solution which is more efficient as well?

file:read_file_info/1 is basically a call to stat(2), at least in UNIX.
So to check using read_file_info and then open requires *two* trips to
the operating system.  And it builds a record, only one field of which
is relevant to the question "could I open this file".  So just calling
file:open/2 is clearly more efficient.

By actual measurement on my machine, a successful call to
file:open(File_Name, [read]) takes 0.23 milliseconds (including
a successful call to file:close(Device)), while
a successful call to file:read_file_info(File_Name) takes 0.27 milliseconds.

	In these cases, I'd be willing to live with read_file_info()
	telling me that I should be able to expect it to work, and
	then file:open() throwing an exception if it still doesn't.
	
In that case you are willing to live with a limit of opening
2000 files per second on my machine, while I would be able to open
4000 files per second.  I also tried a measurement that involved
opening and reading a small file, which is clearly more useful.
open+read+close: 0.54 msec, read_file_info+open+read+close: 0.91 msec.
So I could read 2000 small files per second, while someone who checks
every time with file:read_file_info/1 could only manage 1100 files per second.

I really honestly cannot see any sense in living with an unreliable method
when the reliable one is so much faster.

And of course file:read_file_info/1 is useless for answering the question
"would I be allowed to open this file for output".

Note that my argument against using file:read_file_info/1 to approximate
the question "would I be able to open this file" instead of using
file:open/2 to get an exact answer is *NOT* an argument for tagged tuples.
It is an argument against using file:read_file_info/1 in this way;
file:open/2 would still be the simpler faster method if it could only
return a device or raise an exception.