|
Boost : |
From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-02-28 14:15:26
From: Beman Dawes [mailto:bdawes_at_[hidden]]
>
> At 09:40 AM 2/28/2002, Stewart, Robert wrote:
>
> >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.
I completely overlooked those; I don't traffic in <cstdio> often.
std::remove() and std::rename() rely on errno to report specifics of
failures, which is quite awkward, so those aren't very good for our
purposes.
> 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.
I often do that myself, but I don't do it when failure is expected to be
common.
> 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.
I appreciate your concern. My experience has been that failure of these
operations is common, so the overhead of throwing exceptions will be painful
in at least some cases.
Rob
Susquehanna International Group, LLP
http://www.sig.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk