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

Subject: Re: [boost] [system][filesystem v3] Question about error_codearguments
From: Nevin Liber (nevin_at_[hidden])
Date: 2009-10-29 16:23:53

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.  This is exactly the reason to use assert, not exceptions.

It is hard enough to do this kind of mechanism correctly.  For instance, if
you look at the code as posted, assignment doesn't have the correct
semantics, and is hard to get correct without reference counting, which
would put its overhead in the realm of shared_ptr (a heap allocation for the
reference count).  I've done this kind of thing in very limited
circumstances (assert if the error code isn't checked), and I ended up with
a class that was "Moveable" (in the same way that auto_ptr is "Moveable", as
this is pre-C++0x code) but not Assignable.  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), and you are
coming up with a mechanism that is both hard to use correctly and hard to
reason about.

I briefly considered mentioning asserting in my last post, but chose not to
> just to focus on the other ideas.  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 (where "assert" is short hand
for the more general "put the program back into a known state.  On normal
programs, just abort; on more safety critical programs, that is an exercise
left to the programmer" kind of thing).
-- 
Nevin Liber  <mailto:nevin_at_[hidden]>  [phone]
Sent from Chicago, IL, United States