Boost logo

Boost :

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-11-03 17:12:42

--- Peter Dimov <pdimov_at_[hidden]> wrote:
> E. Gladyshev wrote:
> > --- David Abrahams <dave_at_[hidden]> wrote:
> >> "E. Gladyshev" <egladysh_at_[hidden]> writes:
> >>> 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?
> If you use exceptions to indicate that something is fundamentally broken,
> that's your own problem. Formal correctness theory doesn't acknowledge or
> care about such situations. Once something is fundamentally broken, there
> are no guarantees. None. You are in another dimension where formal theory
> simply doesn't apply.

I don't use exceptions to indicated that something
is fundamentally broken. If something is fundamentally
broken it is usually out of your control.
You don't even get a chance to throw an exception.

I agree with the theory. But we are talking about
practical applications of basic guarantees in terms
of exception safety. In practice, there seems to be
no way to tell what generated
an exception so in general,
basic guarantees don't give exception safety?


Do you Yahoo!?
Exclusive Video Premiere - Britney Spears

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