Re: [boost] Re: Re: Sockets!

From: Wynand Winterbach (wynand_at_[hidden])
Date: 2003-10-30 10:52:40

On Thu, Oct 30, 2003 at 02:47:47PM +0100, Bronek Kozicki wrote:
> Wynand Winterbach <wynand_at_[hidden]> wrote:
> 
> > I agree that the exception reason must be codified into the type name.
> > It is a bit of work to code like this, but I for one find it a lot
> > easier
> > to understand the code (provided that proper names are given to
> > exceptions).

I guess I made it sound as if I'm in favour of huge hierarchies. This is,
IMHO as difficult to use as when there is no hierarchy.

I'm not an expert at all with socket programming, so I cannot dictate
how such a hierarchy should look. This calls for a pragmatic approach,
since one could hem and haw about the perfect hierarchy forever.

Anyone up to the effort of coming up with a decent error hierarchy?
I would have, had I the credentials, but I have no illusions over
my abilities.

As for a different namespace? I quite like defining my exception classes
within my main classes, but this in fact does introduce an unnecessary
logical coupling, which is only needed when you have a templatised class
where your exception depends on the template parameter (somewhat like
iterator definitions for the STL containers). I don't know, I'm really
not a guru. So yes, maybe just another namespace, but not class nesting. 

Again, just my R0.02 worth (R = South African Rand).

--Wynand

> why don't we just make *small* hierarchy of exceptions, all derived from
> "socket_error" derived from "std::runtime_error" ? I hope that main LWG
> objection was agains large number of exception classes, and I feel that
> 20 might be bit too many. Here "too many" means : it might be difficult
> to define (and use correctly) them, assuming each exception class has
> different meaning.
> 
> Another point: currently C++ standard defines only small set of
> exception. I can perfectly understand Committee objections against
> extending this hierarchy with many exception classes, specific to few
> problem domains. Maybe defining namespaces (specifit to these domains)
> inside std namespace, or defining exception classes inside other (domain
> specific) classes could dismiss *some* objections (while rising others),
> that's just my blind guess.
> 
> 
> B.
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost