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 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