[boost] Re: Sockets!

From: Weston Markham (wmarkham_at_[hidden])
Date: 2003-11-06 12:20:34

Hi.  It is likely that I am missing something, but the most recent posts
from Jessie seem to indicate to me that the more specific information
about the condition is only available through the enumeration.  I am
arguing against this restriction:  even though the enumeration provides
a way to get the most specific information about the condition, an
exception that is thrown should also communicate this same
information through its type.

Weston

Quoting Jessie from Friday (
news://news.gmane.org/bnu2i4%24jt4%241%40sea.gmane.org
):

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

Joel Realubit wrote:

> i think Jessie Hernandez already has a good handle on the situation
> though, with a hierarchy of categories of exceptions and specific error
> codes under each category. i look forward to seeing how his work turns
> out... ;-)