For a library function: Some system errors are best handled by aways throwing an exception. For example, a constructor should always throw if there is no way to leave the object in a valid state when a system error is encountered. Some system errors are best handled by ignoring the error. For example, an error in a destructor. But for all the other cases, the recommended approach is to provide throwing and non-throwing versions of the function, and let the user choose which is best for a given use: whatever foo(); // always throws on error whatever foo( error_code & ec ); // never throws on error 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? --Beman