Re: [boost] Re: Sockets!

From: Joel Realubit (joel_at_[hidden])
Date: 2003-11-06 03:03:54

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

Joel Realubit

Weston Markham wrote:

>I would like to try to add a concrete example of why I agree with
>these rules of thumb.  (And, just in case it really is a popularity vote, to
>make sure that my vote counts!)  It has been a while, however, since
>I have done any work with sockets.  Please let me know if my attempt
>to be concrete fails by not making any sense within that domain, so
>that I try to work out a better example.
>
>If users write (or are "forced" to write) client code like:
>
>try
>{
>    ...
>}
>catch( const socket_base::bind_failure& e )
>{
>    if( e.reason() == socket_base::already_bound )
>        ...
>}
>catch( const socket_base::connect_failure& e )
>{
>    if( e.reason() == socket_base::connection_refused )
>        ...
>}
>
>
>...then an author of a new protocol's implementation will have difficulty in
>expressing any exceptional condition that is particular to that protocol,
>in a way that fits within the established framework.
>
>Suppose that the new protocol in question can fail at "connect" time for
>a number of reasons.  I'll call one of these reasons "nonexistent_port",
>and another one "insufficient_resources".  Both of these involve
>communication with a remote host that refuses the connection.
>
>So, in order for the above code to continue to work as intended, these
>conditions must be indicated by the implementation throwing, in both
>cases, some instance of connect_failure that returns connection_refused
>as its reason().
>
>Perhaps "insufficient_resources" is a condition that is fairly transient in
>nature.  A reasonable strategy for handling it might be to wait a few
>seconds and retry.  "nonexistent_port", however, might indicate some
>sort of configuration problem.  Perhaps the client code ought to inform
>the user and let them sort out how to deal with it.  So, how can client
>code that is aware of these new exception conditions distinguish
>between them?
>
>Even if the author of the new kind of socket is able to make changes to
>the connect_failure class in order to support this new protocol, this leads
>to a very ugly, non-OO design.  Sockets are intended to abstract an
>unspecified number of different underlying communication mechanisms.
>So the details of one of these mechanisms shouldn't show up in the
>general classes.
>
>In this scenario, the only satisfactory solution is for the author to subclass
>connect_failure.  So, we are back to modeling exception conditions with
>a class hierarchy, even despite our attempt to "minimize" the number of
>exception classes.
>
>There's also a "slippery slope" sort of argument:  if a design goal is to
>avoid "too many" classes, then where is the cutoff?  Is 5 too many? 2?
>1?  I hope that it is clear that there is an inherent danger there.  By
>contrast, if one deliberately creates "too many" exception classes, (let's
>create connection_refused_on_a_tuesday and
>the_dog_ate_my_network_interface!) but fits them into some
>meaningful hierarchy, the only problem is inventing names for them all!
>(Well, I exaggerate, but hopefully my point is clear.)  As a rule of
>thumb, if an exceptional condition is a coherent enough concept that it
>already has a name, then it seems to me that it is a good candidate for
>an exception class.
>
>Anyway, in short, I believe that a hierarchy of types provides a better
>model for exceptional conditions than an enumeration of values.
>
>I also, by the way, understand that sometimes market forces are even
>more important than perfection.  If, for some reason, potential users of
>a library will actually refuse to use it because they are unable to write an
>exception handler in the style that they like, then it is better to allow that
>style then to leave the library unused.  At worst, you can create an
>enumeration that documents the known types of exception, but still
>throw instances of more specific classes.
>
>
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>  
>