Re: [boost] [system][filesystem v3] Question abouterror_codearguments

Subject: Re: [boost] [system][filesystem v3] Question abouterror_codearguments
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2009-11-01 18:26:30

"Emil Dotchevski" <emildotchevski_at_[hidden]> wrote in message 
news:c72e33ce0910291442k3a989264v25a367c19a4cdc05_at_mail.gmail.com...
>On Thu, Oct 29, 2009 at 2:20 PM, Michael Fawcett
><michael.fawcett_at_[hidden]> wrote:
>> On Thu, Oct 29, 2009 at 5:07 PM, Emil Dotchevski
>> <emildotchevski_at_[hidden]> wrote:
>>> On Thu, Oct 29, 2009 at 1:46 PM, Stewart, Robert <Robert.Stewart_at_[hidden]> 
>>> wrote:
>>>> It's simple:
>>>>
>>>> if (error-not-checked && !std::uncaught_exception())
>>>> {
>>>> throw something;
>>>> }
>>>
>>> http://www.gotw.ca/gotw/047.htm
>>
>> I've read that article before. To me it only seemed applicable to
>> destructors that actually did something, like a rollback. For an
>> object that does nothing in its destructor, do you think Herb's
>> arguments still apply?
>
>The point is that a destructor could call a function that returns this
>sneaky error code object, and end up throwing an exception. You can
>argue that this is a bug, but that's exactly why it is evil -- for
>anything but a trivial toy example, such code can't reasonably be
>tested because it is very difficult to reproduce the conditions that
>could possibly lead to abort().

imho gotw-047 does not apply here:
- the "unsound" objection does not apply here because with "smart_error_codes" 
it is not the callee (T::~T in the example) that decides whether to throw or 
not...it is the caller...and the caller is the (U) destructor (i.e. the writer 
of the destructor) that knows that it does not want throw...and with 
"smart_error_codes" it does not have to use try-catch to swallow/handle the 
exception it simply "inspects" the returned "smart_error_code" and thus both 
disables exceptions and handles a possible error condition...
(maybe i shoudn't have used the exact example from gotw-047 because it uses a 
destructor in a destructor and destructors cannot return values...but i hope 
the argument is still clear)
- the "unmoral" objection does not apply here because the caller is not forced 
to handle both flavours of error reporting...the user is given the "power" to 
choose which method suits best...and it also forces the programmers to check 
for errors, whichever method is used ;)

imho your "evil" objection also does not apply because if a "smart error code" 
object is "sneaky" then so is the T object in the gotw-047 example...in other 
words any function that can possibly throw falls into the category of a "sneaky 
object" (because it can possibly throw in a destructor and cause abort() to be 
called...and because it can only possibly throw it is also not be "reasonably 
tested")...
...i would actually claim quite to the contrary...the "smart error code" 
approach would actually give you a simpler way to disable exceptions in a 
destructor while still handling errors...

>Why not just pick a behavior -- throw on error, or don't throw on
>error -- whichever is correct?

exactly...that's what a "smartened error code" gives you...pick a behavior on a 
call by call basis ;)

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