Re: [boost] Sockets!

From: Richard Peters (r.a.peters_at_[hidden])
Date: 2003-11-04 12:17:35

----- Original Message ----- 
From: "Beman Dawes" <bdawes_at_[hidden]>

> At 04:58 PM 10/30/2003, Peter Dimov wrote:
>  >Bronek Kozicki wrote:
>  >> Peter Dimov <pdimov_at_[hidden]> wrote:
>  >>> Jessie Hernandez wrote:
>  >>> [...]
>  >>>> The above hierarchy, I think, is the best of both worlds: you have a
>  >>>> minimal number of exception classes covering broad types of errors.
>  >>>
>  >>> But _why_ is having a minimal number of exception classes a virtue?
>  >>
>  >> Maybe just because LWG do not like to have many exception classes, and
>  >> we are striving to create something which could be accepted into
>  >> future version of standard C++ library ?
>  >
>  >Please. The LWG members aren't stupid, they are capable of recognizing
> good
>  >design when they see it. We should be striving to come up with the best
>  >design possible.
>
> Yes. In informal discussions, the LWG has already said they would be
> interested in seeing improved designs for exception classes. But my guess
> is that until a design comes along that is "a lot better", they would
> rather make only compatible additions to the current hierarchy. Just "a
> little better" isn't enough to overcome the inertia of an entrenched
> design.

Can't some sort of hybrid-solution be used? A mixture of a hierarchy and
error codes, where the structure of the hierarchy is driven by the need to
catch different situations, and detail to those classes is added in the form
of a specific error code.
For example, in the case of sockets, you have several exceptions like
connection refused, connection aborted by the other side, connection aborted
because of a network problem, protocol not found, etc. In this case, the
different connection aborted exceptions would go in one exception class, and
connection refused and protocol not found each go into different classes,
because they occur in different places and are likely to be treated very
differently. Maybe connection refused and the aborted ones should both
descend from a common baseclass if you want to catch all kinds of connection
failures, but want to differentiate in protocol errors. In pseudocode:

class socket_exception_base {
  int error_code();
};
class socket_connection_error: socket_exception_base;
class socket_connection_refused: socket_connection_error;
class socket_connection_aborted: socket_connection_error;
class socket_connection_protocol: socket_exception_base;

This is not a concrete proposal for socket exceptions, but an example of
making an exception hierarchy 'catch-based' instead of 'throw-based'.
Does this sound ok?

best regards,

Richard Peters