Hello all, I have been thinking about how to reconcile Boost.Asio error handling with the system error classes defined in the TR2 filesystem proposal N1975. I have some concerns which I'll outline in the context of how I plan to use them. The current plan is as follows: - Synchronous functions would by default throw a system_error exception. - An overload of each synchronous function would take an error_code& as the final argument. On failure these functions set the error_code to the appropriate error. On success, the error_code is set to represent the no error state. These functions do not throw exceptions. - Callback handlers for asynchronous functions would take an error_code as the first parameter. For example: void handle_read(error_code ec) { ... } - Since many error codes in socket programming are "well-known" and often tested for explicitly, they need to be defined somewhere. The current errors in the asio::error::code_type enum would be replaced by constants of type error_code: namespace boost { namespace asio { namespace error { const error_code access_denied = implementation_defined; const error_code message_size = implementation_defined; ... } // namespace error } // namespace asio } // namespace boost (Note that in practice boost::asio::error might actually be a class with static members rather than a namespace). The issues I have run into so far are: - The error_code class seems to assume that there is a single "namespace" for the system_error_type values. This is not necessarily the case for the errors in socket programming. For example on UNIX most socket functions use errno values, but the netdb functions (gethostbyname and friends) use a different set of error values starting from 1, and the getaddrinfo/getnameinfo functions use another set of error values starting from 1. Would it be possible for the error_code class to have a category value (which is probably an integer with implementation-defined values) to allow the creation of unique error_code values for each type of system error? A category value would also allow implementors and users to extend the system error classes for other sources of system error (e.g. SSL errors, application-specific errors, etc). - A common idiom in code that uses asio, when you don't care about a specific error type, is to simply treat the error as a bool: void handle_read(asio::error e) { if (e) { // take action because of error } else { // success } } Can the error_code class be made convertible-to-bool and also have operator! to support this style? - Are these classes available in CVS somewhere so they can be reused by other boost libraries? Cheers, Chris