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

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 
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.

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 
ignored.

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.

--Beman

--Beman