From: David Abrahams (dave_at_[hidden])
Date: 2005-04-27 21:27:23
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. 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.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk