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://listarchives.boost.org/mailman/listinfo.cgi/boost
>
>
>