BOOST WIKI | BoostSocket | RecentChanges | Preferences | Page List | Links List

SocketError Concept

Most error returns should be converted into platform neutral exceptions.

The exception to this would be the non-blocking "errors".

enum SocketError?

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...

Error handling policy

[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.

      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;
            // 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)

No exception alternative

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

List discussions

H. Mackenzie has started an discussion of socket errors. See http://lists.boost.org/MailArchives/boost/msg39663.php

BOOST WIKI | BoostSocket | RecentChanges | Preferences | Page List | Links List
Edit text of this page | View other revisions
Last edited December 18, 2004 12:25 pm (diff)
Disclaimer: This site not officially maintained by Boost Developers