From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-11-03 16:43:46
--- David Abrahams <dave_at_[hidden]> wrote:
> "E. Gladyshev" <egladysh_at_[hidden]> writes:
> >> This has *nothing* whatsoever to do with the basic guarantee, other
> >> than that the basic guarantee is phrased in terms of invariants. Any
> >> condition arising from this fact that you can conjure up with
> >> exceptions can also be created without them. I suggest you drop
> >> discussion of the basic guarantee and exceptions for the time being and
> >> just look at invariants in stateful programming.
> > The point of my question was how to use basic guarantees
> > in practice especially in case of an exception.
> > Usually I am making two assumptions.
> > If there is an an exception then:
> > 1. There is a problem with the hardware.
> > 2. The program is incorrect and the invariants,
> > integrity of the memory and program stack can be broken.
> > In both cases, I don't think that it is safe to do anything.
> Right. But both those assumptions are in general wrong. Exceptions
> are thrown when postconditions can't be satisfied ("I can't allocate
> enough memory to resize this vector"), not when something's
> fundamentally broken in the program or hardware.
Ok, but how do you differentiate "fundamentally-broken"
exceptions from "good" exceptions in your code?
> > Do program invariants or basic guarantees change anything
> > in how you handle exceptions?
> I don't understand the question.
As far as I understand basic guarantees make it possible
to use objects in case of an exception.
//my_type provides basic guarantees.
my_type *p = new my_type;
//basic guarantees allow you to delete 'p' safely!!!
Is it *really* safe to delete 'p' even if it provides
We agreed (?) that the program my be "fundamentally" broken
at the time when we caught the exception.
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk