[Home]BoostSocket/SocketErrorConcept

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

Difference (from prior major revision) (no other diffs)

Changed: 1,102c1,74

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

** Winsock2 : enum SocketError? {Success=0, WouldBlock?=WSAEWOULDBLOCK};
** unix : enum SocketError? {Success=0, WouldBlock?=EAGAIN};


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.

ErrorPolicy?
int handle_error()

socket_exception




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

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


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.

    ErrorPolicy?
      int handle_error()

socket_exception

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

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)
Search:
Disclaimer: This site not officially maintained by Boost Developers