Boost logo

Boost :

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:

    catch (...)

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

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.

Susquehanna International Group, LLP

Boost list run by bdawes at, gregod at, cpdaniel at, john at