At 08:51 PM 3/31/2005, David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
Beman Dawes wrote:
At 01:06 PM 3/31/2005, Rob Stewart wrote:
I disagree. All the caller wants to know is whether the supplied pathname refers to an existing file.
But if it isn't possible to reliably answer that query, shouldn't it be an error?
The answer to this question is probably "no", if by error you mean exception, and here is why.
Every exception-throwing function has spawned a predicate that is used to
avoid the exception (because exceptions cancel the currently active operation and this is undesirable in some cases).
Separate predicates don't really help you avoid exceptions reliably in filesystems because of race conditions. But y'all know that. Why have we gone down that road...
One way of looking at the current discussion is that we are trying to avoid going down that road.
... as opposed to having an argument that can be used to say "don't throw?"
The other semantics of throwing and non-throwing functions may be different. The importance of avoiding race conditions may be different. That's why I'm thinking of separate functions distinguished by function name rather a "don't throw" argument. However, a stat()-like function might have both throwing and non-throwing versions, with no other differences, so that might be a candidate for a throw/don't-throw argument. --Beman