Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-03-19 22:44:57


Yes, but how do you document a function's behavior?
"may throw an exception due to low memory or insufficient resources, or if
the user passes an invalid object. In the latter case there is no guarantee
that the operand is left in a consistent or even destructible state"

I believe in simple contracts, guarantees, and invariants. Simple this aint.

-Dave

----- Original Message -----
From: "Jesse Jones" <jejones_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, March 19, 2001 7:47 PM
Subject: RE: [boost] Re: Boost.Threads draft library submission

> >Another aside: Please note that nothrow operations are a cornerstone of
> >exception-safe code. One great value of assertions is that they can be
used
> >liberally without fear of affecting the shipping program's efficiency or
> >semantics (assuming side-effects are avoided). If we start using
assertions
> >which may sometimes throw, we will have to account for the fact that a
> >sequence of operations that might have been nothrow suddenly loses that
> >property. The program is now expected to be able to function correctly
(or
> >at least recover) when arbitrary operations have been interrupted by
> >exceptions. I don't like this complication, and would prefer to very
> >carefully distinguish a throw from an assert().
>
> Well it's not like having asserts throw is going to magicly make
programmer
> errors recoverable. Presumbably clients are enabling throwing because they
> don't want the program to silently return bad results, but they also don't
> want to simply shut the app down. So all that they are doing is playing
the
> percentages and hoping that the app will remain useable even if one of two
> features sometimes wind up asserting. The exception afety issues just
> reduce that chance by a bit...
>
> -- Jesse
>
>
>
> List-Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk