Most error returns should be converted into platform neutral exceptions.
The exception to this would be the non-blocking "errors".
Provide a Success constant. Provide constants for other "errors" that are not treated as exceptions, ie WouldBlock?.
Hamish Mackenzie has request three types of non-exception return value
success > 0 want_read = -??? want_write = -???
A write on an ssl stream can block attempting to read from the underlying socket (and vice-versa)
We need a little more explanation of this idea...
[Updated to reflect some of H. Mackenzie comments. See http://lists.boost.org/MailArchives/boost/msg39663.php]
If a platform API function returns !Success, then handle_error should raise an appropriate exception or translate to a SocketError? value defined above, or another value defined by the error policy.
Error handling should be done through a policy class to allow the tuning of expceptions vs return values.
ErrorPolicy? int handle_error()
Base class for socket exceptions. Not thought about this much....
Should be derived from std::exception ?
Any additional information to provide ?
My suggestion would be (Michel):
class socket_error : public std::exception { std::string m_what; public: // In my implementation of ip_address I use format // classname::member->apifunc eg ip_address::ip_address->getaddring error(const std::string& function, int ecode); error(const std::string& function, const std::string& text); // compiled string consisting of function - error_text - error_code const char* what() const; int error_code() const; std::string error_text() const; // os dependent error text for error_code (eg gai_strerror or similar) };
Adaptive Communication Environment (ACE) supports a no exception error handling policy by default, but allows an exception based policy by compilation changes. I agree that boost.socket should use exceptions by default, but it might be wise to also allow BOOST_NO_EXCEPTIONS to be defined with an appropriate user error handling function. Since this complicates the design I would be happy with this being a future goal, but not a requirement of the first design.
In that case we would need to define some is_valid or last_error on some of the concepts eq the address concept so we can handle initialization with malformed strings. /michel
H. Mackenzie has started an discussion of socket errors. See http://lists.boost.org/MailArchives/boost/msg39663.php