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

Subject: Re: [boost] [system][filesystem v3] Question about error_codearguments
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-10-29 16:46:37

Nevin Liber wrote:
> 2009/10/29 Stewart, Robert <Robert.Stewart_at_[hidden]>
>
> > Yes, I was aware of those issues.  However, the point of the
> > exception here is to flag that the client failed to do what
> > should have been done: check for errors.  To be helpful, the
> > original error information is passed along, but that is most
> > helpful, in my mind, to help identify the place where the
> > failure to check occurred.  That the exception won't be
> > thrown in certain contexts doesn't mean it isn't useful in
> > the rest.
>
> In other words, a programming error (failure to check an
> error return) is
> detected.

That's how I understand what's been proposed.

> This is exactly the reason to use assert, not exceptions.

Certainly, assertions are the best tool, but not everyone tests debug builds or covers all branches when testing them.  You could argue that calling std::abort() or std::terminate() is a better choice when the assertion is compiled out.

> It is hard enough to do this kind of mechanism correctly.

It would be done once by a library.

> Now add in the complication of throwing unless there is a throw
> in progress (if you have an example of how to do this, please
> post a link to working code which does it)

It's simple:

   if (error-not-checked && !std::uncaught_exception())
   {
      throw something;
   }

> , and you are coming up with a mechanism that is both hard to
> use correctly and hard to reason about.

It isn't so hard, really.  If you call a function that populates an error_code passed to the function by non-const reference or pointer, and you fail to inspect that error_code to see whether there was an error, that error_code will do nasty things to your program at runtime.  If using a debug build of the library, you'll get an assertion.  If not, the library will call std::abort() (or whatever) or throw some exception.

> > To throwing an exception when there isn't a pending
> > exception, we can assert, in debug builds anyway, when the
> > error isn't checked.  Thus, the developer should get an
> > assertion failure pointing to the error_code that wasn't
> > checked.  If the assertion is disabled (non-debug build,
> > say), the application will get an exception in most
> > circumstances.
>
> What good does that do?  I can't think of any circumstance
> where I'd want to not assert when I detect a programming error

assert is a macro that is typically disabled in non-debugging builds.

> (where "assert" is short hand for the more general "put the
> program back into a known state.  On normal

That is not what I mean by "assert" and I've never heard it defined as you have here.

> programs, just abort; on more safety critical programs, that
> is an exercise left to the programmer" kind of thing).

One can imagine error_code::set_unhandled_error_handler() to register a handler to customize what occurs when a programmer fails to check an error.  If no handler is registered, the behaviors mentioned above could provided by default.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.