Re: [boost] Re: Re: Re: Sockets!

From: Scott Woods (scottw_at_[hidden])
Date: 2003-10-30 18:35:08

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Friday, October 31, 2003 11:26 AM
Subject: Re: [boost] Re: Re: Re: Sockets!

> Scott Woods wrote:
> > ----- Original Message -----
> > From: "Peter Dimov" <pdimov_at_[hidden]>
> > To: "Boost mailing list" <boost_at_[hidden]>
> > Sent: Friday, October 31, 2003 9:08 AM
> > Subject: Re: [boost] Re: Re: Re: Sockets!
> >
> >
> >> 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?
> >> _______________________________________________
> >
> > My $0.02
> >
> > If there is a general acknowledgement that exception-hierarchies
> > and exception-classes-returning-codes are two valid error-propagation
> > techniques then;
> >
> > * maybe the "perfect balance" for the use of both is something decided
> > by the author of each piece of software (subject to reviews of
> > course).
> > * exception-hierarchies cannot be "passed on". with classes-returning-
> > codes it is pretty trivial to detect an exception and then pass codes
> > to other methods/functions. doing something equivalent from inside
> > a catch() {} is not the same. for this reason I do minimize the number
> > of exception classes. but maybe laziness is not a valid influence on
> > the balance of "exception-hierarchies and
> > exception-classes-returning-codes"
>
> You seem to forget that these two approaches are not mutually exclusive.
You
> can still have a member function of the base of the hierarchy that returns
> the error code, allowing users that are only interested in the error code
> (to translate it into a message to be displayed, perhaps) to catch all, or
> part, of the hierarchy.

If it sounded like that, it was not intentional. I "mix it up" in the error
propagation
for any particular lib. Yes, I still use "return -1" as well :-)

Would count it as a special case where the "base of the hierarchy that
returns
the error code" is the base of all exceptions. For example, I have
high-browed
intentions that the base is always "standard" exception; I regularly fail
(throw? :-)
But yes I see what you mean.

So maybe all the different applications of the two propagation techniques
are valid, i.e. committing to the granddaddy-base-of-all-exceptions
obviously
will have/does have its place?

In the case where there is an exception hierarchy (or sub- hierarchy) with
no
base-with-code, there is a much stronger influence on the library user to
deal
with errors "in-situ". The chosen propagation technique constrains the user.

Just another design consideration for the library author.

Cheers,
Scott