Re: [boost] Re: [Filesystem] i18n

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