Rob Stewart <stewart@sig.com> 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
At 10:27 PM 4/27/2005, David Abrahams wrote: 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