Re: [boost] [system][filesystem v3] Question about error_codearguments

Subject: Re: [boost] [system][filesystem v3] Question about error_codearguments
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-10-28 19:01:16

On Wed, Oct 28, 2009 at 3:46 PM, Domagoj Saric <dsaritz_at_[hidden]> 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_; )
>>>
>>> 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
>>> 17.6.4.10 Restrictions on exception handling
>>> [res.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
> issues unintentionally...
> 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')...

It

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

Assuming that there is an agreement that the user *knows* if she wants
an exception or an error code, why not provide two functions: one that
returns an error code, and another one that calls the first one and
throws on error?

>
>
> --
>  "That men do not learn very much from the lessons of history is the most
> important of all the lessons of history."
>  Aldous Huxley
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode