In-Reply-To: <dta3ga$o0b$1@sea.gmane.org> bdawes@acm.org (Beman Dawes) wrote (abridged):

Fresh draft up at www.esva.net/~beman/error_reporting_guidelines.html.

At first sight this involves writing functions twice, one version that throws system_error and another version that returns system_error_code_type. Is that burdensome in practice? Some code examples might help. Is this the kind of thing you have in mind? int my_close( int fd ) { system_error_code_type error; int result = my_close( fd, error ); if (error != 0) throw_exception( system_error( "close", error ) ); return result; } Looking at this, it seems to me it might be better if the caller sets system_error_code_type to 0, rather than the callee. It's not nice for the caller to have an uninitialised variable, and there's no need for them both to do it. Is 0 a reasonable "non-error" value for all platforms? It is tempting to use a more elaborate type here, eg one that adds a bool to flag the error case. Is the code already so unportable that this isn't an issue? Another reason for using a user-defined type for system_error_code_type is better type safety. I am slightly bothered that, as it stands, we are overloading based on an int argument. Isn't that error-prone? It means we can't have function sets like: int func( int ); int func( int, int ); int func( int, system_error_code_type & ); int func( int, int, system_error_code_type & ); even if that is what the user might naively expect. Do you have a scheme for generating the throwing function automatically, via macros or templates? I'm not advocating such a scheme. I am wondering what your thoughts are. -- Dave Harris, Nottingham, UK.