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

Subject: Re: [boost] [system][filesystem v3] Question about error_codearguments
From: Detlef Vollmann (dv_at_[hidden])
Date: 2009-10-29 09:35:11

Stewart, Robert wrote:
> 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.
I'm not so sure about this argument.
What you would probably throw is not the original exception,
but an exception objects of some type like 'unhandled_error'
that has inside the original exception data.

This was discussed with a bit different perspective:
For a lot of system level calls, you could get quite a number
of different error codes.  Some of them are not really exceptional
errors (e.g. EAGAIN) in a lot of contexts.  But it's up to
the application what error codes represent exceptional
errors and which don't.
So the call would be something like 'device.read(error_object, ...)'
and error_object would have member functions to query for error codes,
and the destructor would throw, if error_object would contain an error
code that was not queried for.
I believe this is a viable approach.

But the basic problem of throwing exceptions from destructors exists,
and is IMO a major flaw of how exception handling works in C++,
but I don't think that this will change.

   Detlef