Hi Beman, Beman Dawes <bdawes@acm.org> wrote:
Although this works well, it has the unfortunate consequence of doubling the number of functions. That makes the interface harder to understand and is a pain to implement, document, and maintain.
A refinement is for the <error_code.hpp> header to provide a dummy error_code that is interpreted as a request to thrown on errors:
extern error_code throw_on_error;
Then only a single signature is required: ? whatever foo( error_code & ec = throw_on_error );
On an error, the implementation of foo throws if ec != &throw_on_error, otherwise it sets ec to the appropriate error_code and returns without throwing.
This approach gives the user the same choice, but halves the number of functions. I can't think of any downside.
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. On the other hand, under the current approach the "as if" definition of the throwing version is trivial. E.g. for ip_address::to_string() string to_string() const; Effects: Calls: error_code ec; string s = to_string(ec); if (ec) throw system_error(ec); Returns: s. 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. 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. 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. Cheers, Chris