[boost] Re: [Filesystem] i18n

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