Boost logo

Boost :

Subject: Re: [boost] [system][filesystem v3] Question about error_codearguments
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2009-10-30 23:49:36


On Wed, Oct 28, 2009 at 6: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')...
>

bool diff(file srcA, file srcB, file output)
{
   // get our files ready...
   error_code srcA_err = file_open(srcA);
   error_code srcB_err = file_open(srcB);
   error_code out_err = file_open(output);

   if (srcA_err || srcB_err || out_err) // check for errors
      return false;

   // do the diff...

   return true;
}

If srcA_err is true, then srcB_err and out_err aren't checked. On
function exit, out_err throws on destruction, srcB_err throws on
destruction during stack unwinding. (I think.)

So that took a bit of thought for me to come up with, but the code
doesn't look completely unreasonable, does it?

Basically, you never want more than one actual error_code to exist at
a time (per thread). Temporary copies would be OK (should be moveable
anyhow, or ref counted). This could be checked for in the debug
build.

Tony

<p.s. hope this doesn't get posted multiple times - gmail wasn't
responding, so I'm resending...>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk