Boost logo

Boost :

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-07-19 15:36:33

----- Original Message -----
From: Bjarne Stroustrup <bs_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, July 19, 2001 5:14 PM
Subject: Re: [boost] Proposal: statefull objects

> "Fernando Cacciola" <fcacciola_at_[hidden]> writes:
> >
> > In order to introduce this proposal let's consider the following
> >
> > CASE A:
> > =======
> >
> > struct image
> > {
> > ...
> > int get_pixel( int x, int y) const ;
> > ...
> > } ;
> >
> > How should we deal with the case of x,y being outside the image?
> > Unfortunately, it might be the case that every possible integer value is
> > valid pixel color, so no value can be used to signal that there is no
> > at that position.
> > Assume that the function should not throw an exception.
> Why/when is that a good assumption?
All right, I'll refrase it.
Supoose you -the class designer- don't want to throw an exception in the
case the input position is outside the range of the image; you just want the
caller to know it, so she/he can decide whether this is an exception or not.
The std set/map interfaces are good examples of this case: insert() signals
that the element is already contained in the collection using a boolean flag
attached to the returned iterator.

> When used systematically, the "stateful" technique simulates on of the
> techniques for implementing simple exceptions.

I fail to follow you on this.

AFAIK, exceptions were introduced to avoid situations like the above when
the decision of considering it an exceptional situation can be made on the
callee side. I am proposing a common idiom to transfer that desicion to the
caller, where an exception can be thrown if applicable.

BTW, I noticed that I misspelled 'statefull': it should be 'stateful' (with
a single l)

Fernando Cacciola
Sierra s.r.l.

Boost list run by bdawes at, gregod at, cpdaniel at, john at