RE: [boost] Re: Design for a file system library

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-02-28 09:40:44

From: Peter Dimov [mailto:pdimov_at_[hidden]]
> 
> From: "Stewart, Robert" <stewart_at_[hidden]>
> > From: Beman Dawes [mailto:bdawes_at_[hidden]]
> > >
> > > At 07:43 PM 2/24/2002, Jan Langer wrote:
> > >
> > >  >>bool remove(name_t name);
> > >
> > > No return.  Should throw if error.  Other than exists(), 
> all the free
> > > functions should throw on error.
> >
> > I disagree.  This is not such an uncommon failure; using an 
> exception to
> > report it will make code for this frequent, if not common 
> condition, more
> > awkward.
> 
> "Will make code" or "does make code" more awkward, i.e. speculation or
> experience? My experience is that using exceptions for I/O 
> errors makes code
> much less awkward.

"Will make code" as in inescapable, versus "might make code."

If a dtor must remove a file that an object manages, and remove() throws an
exception, then the dtor must do something like this:

    try
    {
        remove(file_);
    }
    catch (...)
    {
    }

If remove() doesn't throw an exception, then the dtor is a simple call to
remove().

Likewise, I/O errors of this sort -- renaming, moving, removing -- are very
common and don't fit well within the "exceptions for exceptional errors"
approach which is often the wise course.

There are two approaches to such functions: return bool or a status code and
wrap to get exceptions, or throw exceptions and wrap to get a bool or status
code.  The question becomes which is the more common and fundamental usage.

My preference is for the functions to return bool/status code because
ignoring the errors doesn't imply a permanent or fatal condition.  Since,
for example, failure to delete a file may be transient, it is not
unreasonable to write a loop that retries several times, with a delay
between tries, before declaring the operation a failure.  Writing such logic
with exceptions is more complicated than it needs to be.

Rob
Susquehanna International Group, LLP
http://www.sig.com