Hi Beman,
- Callback handlers for asynchronous functions would take an error_code as the first parameter. For example:
void handle_read(error_code ec) { ... }
That makes sense to me. It wouldn't be useful to throw an exception because of the asynchronous nature of the control flow, so supplying a error_code to the callback gives it a chance to deal with the error, or ignore it if desired. Was that your analysis?
Yep, exactly. The current asio::error exception class currently fills the role of the error_code in async callbacks, as well as the system_error in throwing sync functions.
I haven't thought of the case of several "namespaces" or "errorspaces" before, so please take what follows as an initial idea, not something cast in concrete.
My initial thought is to leave error_code alone, since it should be fine for most uses. For uses that need more information, such as asio, derive asio_error_code from error_code, adding appropriate members. For example, members to set/get the well known socket error codes.
Couldn't that introduce a problem with slicing? The error_code is passed by value to functions like system_message(), the system_error constructor etc. I suppose I'm not thinking of the asio errors as having more information as such. From the user's point of view they are system errors like any other. It's just from an implementation point of view that we have these multiple error spaces. This is mainly a problem for UNIX where some of the system APIs don't use errno values. When I was thinking about it before, I wasn't sure whether it was better to make the category part of the interface or simply allow the implementation to add a category as part of the implementation-defined system_error_type. Another aspect that appeals to me with having well-known errors as constants of type error_code, is that it allows most users to treat the error_code as an opaque type. They can write: void error_handler(error_code ec) { if (ec == asio::error::eof) ... } without needing to worry about the implementation-defined value of asio::error::eof, or indeed care what implementation-defined error space it lives in.
- Are these classes available in CVS somewhere so they can be reused by other boost libraries?
No. I was waiting for 1.34 to ship, but that is taking a long time so I'll go ahead and update CVS head, hopefully tomorrow.
Great, thanks! Cheers, Chris