Re: [boost] [system] error report refinement

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-08-28 12:28:11

Christopher Kohlhoff wrote:
>> Comments?
> 
> I'm concerned that, even though it may halve the number of
> functions, it actually increases the complexity overall.
> 
> Putting my standards-proposal-author hat on, it makes the
> specification of the behaviour of the single function more
> complex than the original non-throwing version.

The way to deal with that concern is to provide front matter that says:

Unless otherwise specified, all functions taking an argument of 
error_code * do such-and-such. That way you don't have to say it for 
each function individually.

> The increased number of code paths in the single function might
> also make it harder for the compiler to optimise the code. Even
> if you are only interested in using non-throwing functions, you
> could end up with the bookkeeping costs (space or time)
> associated with exceptions whether you like it or not.

Yes, that is a concern.

> Another thought: from an implementation point of view, there's
> no way to ensure that the throw_on_error value is not written to
> accidentally (and it introduces a race condition if you do write
> to it). That increases the burden on the implementor. This cost
> potentially impacts on library users if they want to reuse the
> error_code facility in their own functions.

If we follow Guillaume's suggestion and use a pointer, that problem goes 
away. And I don't think we have much choice; comparing addresses across 
DLL boundaries has gotten me in trouble in the past so I think we have 
to avoid that.

> While I appreciate the goal, I'm not convinced this is an
> improvement over the current method. I suppose my late night
> ramble above is really a round-about way of saying that the
> current error_code policy is better because it distinguishes
> between the two modes (throwing or non-throwing) at compile
> time, not run time.

Yes, and AFAIK there is no need to change behavior at runtime.

Let me think about it a bit. You may be right.

Thanks,

--Beman