|
Boost : |
Subject: Re: [boost] [system][filesystem v3] Question about error_codearguments
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-10-29 08:42:10
Domagoj Saric wrote:
> "Emil Dotchevski" <emildotchevski_at_[hidden]> wrote in message
> news:c72e33ce0910281332m5ec6d444gf249609963661587_at_mail.gmail.com...
> >On Wed, Oct 28, 2009 at 12:40 PM, Detlef Vollmann
> <dv_at_[hidden]> wrote:
> >> Domagoj Saric wrote:
> >>>
> >>> ~error() ( if ( !inspected ) throw actual_error_; )
> >
> >A library should either throw when the error is detected or
> >not. If it
> >doesn't, the user might still throw, but the *library* throwing later
> >seems a very bad idea. Not to mention the issue that throwing in a
> >destructor can end up calling abort().
>
> if you just ignore the return...the function will appear to
> throw just as if it
> threw 'from within'...if you inspect it it 'magically' starts
> to behave as if it does not throw but returns an error code...
>From a debugging perspective, the exception will be thrown at the wrong point.
> ..._only_ if you save the returned object into a local scoped
> variable _and_ do
> not inspect it can the issues of "library after throw" and
> "abort on exception
> in destructor during unwind" come into play...
The complexity of this magical behavior, the problem with throwing in the caller rather than at the point of error, the overhead of checking to see whether to throw at each call site, and the danger of throwing in the destructor during stack unwinding, makes overloading each affected function a pleasant alternative.
_____
Rob Stewart robert.stewart_at_[hidden]
Software Engineer, Core Software using std::disclaimer;
Susquehanna International Group, LLP http://www.sig.com
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk