[erlang-questions] Exceptions vs Tagged Values
Richard A. O'Keefe
Tue Nov 14 23:27:54 CET 2006
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.
More information about the erlang-questions