Re: [boost] Re: [filesystem] Operations predicates

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-05-04 09:25:49

From: "Beman Dawes" <bdawes_at_[hidden]>
> "Rob Stewart" <stewart_at_[hidden]> wrote in message 
> news:200505031504.j43F48eL022587_at_weezy.balstatdev.susq.com...
> > From: "Peter Dimov" <pdimov_at_[hidden]>
> >> Beman Dawes wrote:
> 
> >  But it does mean that it is easy to ignore problems in
> > calling status() ...
> 
> Yes, but otherwise identical functionality is available using the is_xxx() 
> and exists() functions, which throw on errors. They would be preferred 
> unless the program specifically needs to treat errors as non-throwing.

Yes, folks will choose to use status() when they want nonthrowing
behavior, but why design an interface that makes it easy to
forget about the error code?

> >and that one must read the error code before
> > calling it again.
> 
> Yes.
> 
> > Perhaps the flags could be accumulated with the error code in a
> > class that has a safe-bool conversion?
> 
> That's a possibility, although I think I like Peter's suggestion better just 
> because it is a bit simpler.

I assume you're referring to this:

   status_flag status(path const &, int * error = 0);

It is simpler from an implementation standpoint, but I don't
think it is simpler from the caller's perspective.  Since the
argument is defaulted, the compiler will offer no help to ensure
that you get and inspect the error number.

Returning a type with the flags and error number together means
that you always get the error number and can inspect it.  Whether
you use any schemes to ensure that the caller inspects a non-zero
error number -- such as asserting in the destructor if an
"inspected" flag isn't set -- is another matter.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;