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

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

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

-- 
 "That men do not learn very much from the lessons of history is the most
important of all the lessons of history."
 Aldous Huxley