Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at