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
>>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk