From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-28 13:29:14
At 09:40 AM 2/28/2002, Stewart, Robert wrote:
>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
>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
>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
>wrap to get exceptions, or throw exceptions and wrap to get a bool or
>code. The question becomes which is the more common and fundamental
>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.
The current std::remove and std::rename aren't going to go away; you can
still use them if you wish.
But for a new design, I prefer to depend on exceptions as the error
reporting mechanism. I've just seen too many programs that fail to check
for I/O errors. At least with exceptions the errors won't be silently
Once we gain some experience actually using the library, we can always add
unchecked_move() or similar. But that should be only an experienced based
fallback, not the default behavior.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk