From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-05-02 16:53:24
At 10:27 PM 4/27/2005, David Abrahams wrote:
>Rob Stewart <stewart_at_[hidden]> writes:
>
>> For example, if I'm expecting to read a file and I cannot, I
>> typically report that fact and leave to the user the job of
>> figuring out what's wrong with the file or path to it. That
>> approach is handled by a non-throwing is_xxx().
>>
>>> > That's not to say that it need be
>>> > sloppy, but it is often more forgiving. I'll again refer to my
>>> > years of writing shell scripts on *nix. The -d test never
>>> > generates a signal (the moral equivalent of an exception in C++
>>> > in this case); it just returns true or false. That simplicity
>>> > makes it easier to write scripts, though I'll grant that it does
>>> > mean you have to be a little careful to not make too many
>>> > assumptions about what ! -d means.
>>>
>>> That's fine, but the default should be to not ignore errors, rather
than
>the
>>> other way around, IMO.
>>
>> As we've said, this doesn't ignore errors, it just classifies
>> them as cases that mean is_xxx() returns false.
>
>Right. Beware interface designs that avoidably classify inputs as
>abuses. Some people wanted to make a mathematical vector type for
>which you'd get an exception if you tried to assign a vector of one
>length into a vector of some other length. I argued with them. There
>was no reason not to simply resize the target vector. Similarly,
>there's no reason not to simply report false when is_xxx(p) doesn't
>find anything at path p.
That's also the conclusion I came to in the analysis. "not found" isn't an
error, it simply returns false. "I/O error", OTOH, is an error, and so the
functions should throw an exception for this case.
> Actually, I'd almost be inclined to drop the
>is_xxx(p) function because the result becomes meaningless the moment
>you get it back: the xxx may or may not exist or be of the right type,
>no matter what the result is.
In theory, that is certainly correct. But in practice a lot of filesystem
work is done in environments where race conditions are not present, and
these functions are very, very convenient.
--Beman