2009/10/29 Stewart, Robert <Robert.Stewart@sig.com>
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@eviloverlord.com> (847) 691-1404 Sent from Chicago, IL, United States