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:
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk