Subject: Re: [boost] [system][filesystem v3] Question about error_codearguments
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2009-10-28 18:46:38
"Emil Dotchevski" <emildotchevski_at_[hidden]> wrote in message
>On Wed, Oct 28, 2009 at 12:40 PM, Detlef Vollmann <dv_at_[hidden]> wrote:
>> Domagoj Saric wrote:
>>> ~error() ( if ( !inspected ) throw actual_error_; )
>> This was discussed in the POSIX/C++ meeting 10 days ago, and was
>> considered to be a good idea.
>> Unfortunately, in the current C++ working paper, we have in
>> 22.214.171.124 Restrictions on exception handling
>> "4 Destructor operations defined in the C++ standard library
>> shall not throw exceptions. "
>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().
i mentioned the latter 'issue' already in the first post...
generally both points seem to me like non-issues because they cannot become
both can come into play _only_ if the user converts the temporary return object
into a local scoped object/variable...which, as far as i know, you cannot do
'by accident'/unintentionally...you have to be verbose about it...(although,
ironically the new auto makes it easier for you to do "the wrong thing"...but
still not easy enough that you can do it by a 'non conscious mistake')...
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...
..._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...
only/one of the draw backs i can see here is a certain amount of bloat, for
those that would mostly choose the throw option (not to inspect the error ),
compared to the case where the throw would come from within because now the
throwing and 'if' logic would be duplicated into every caller function (instead
of just being in one place...the function that actually 'produces' the
-- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk