[boost] Re: Sockets!

From: Jessie Hernandez (jessie_at_[hidden])
Date: 2003-10-31 11:29:10

"Christopher Currie" <christopher_at_[hidden]> wrote in message
news:3FA160B1.5040504_at_currie.com...
[snip]
> Exceptions are seen as being more OO-like, but they have performance
> penalties that are unacceptable in some situations. Ultimately, we might
> be best off implementing some variation of the iostreams model: define a
> collection of error codes, and the user is able to set an exception mask
> to determine which errors generate exceptions.
>

I had initially considered this approach, to emulate the
basic_ios::exceptions(), but later thought of an error policy because
different domains can have exceptions specific to that domain, so all the
error flags might not be known beforehand. Now, if we can assume that all
socket exceptions fall under some general categories (such as bind_failure,
connect_failure, create_failure, etc.), then I can use this approach (of
course, naming the member function "socket_exceptions" so it doesn't
conflict with "exceptions" in basic_socketstream).

I will be looking at all possible socket exceptions (in both Linux and
Windows) and see under what logical category these exceptions lie, and
create additional categories as needed. I just looked at the
/usr/include/asm/errno.h file to see all the possible socket errors under
Linux, and I came up with the following exception classes (subject to change
after I look at the Windows errors). The name to the left is the name of the
exception that will be thrown, and the names to the right form part of an
enum (which will shared by all exceptions, defined in socket_base) that will
indicate the exact reason for the failure.

- bind_failure (address_protected, already_bound)
- connect_failure (connection_aborted, connection_reset, already_connected,
not_connected, endpoint_shutdown, connection_refused)
- host_failure (host_down, host_unreachable, host_not_found)
- network_failure (network_unreachable, network_reset, network_down)
- permission_denied
- protocol_error (protocol_not_found, protocol_not_supported,
unknown_protocol)
- service_error (service_not_found)
- socket_base::failure
- timed_out

Clearly, if I stayed with the full-exception hierarchy I had before, and
made an exception for each of these specific errors, then it would get
really messy, IMHO. Defining just these general categories of exceptions and
having an enum to get detailed error reasons looks like a very clean design
to me.

I am convinced that this is the best design for the socket exceptions, and
it models the iostreams model, as you mentioned. Thanks for bringing this
point up. I will remove the error_policy template parameter and have the
exception classes mentioned above soon.

--
Jessie Hernandez