From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-11-03 17:33:18
E. Gladyshev wrote:
> --- Peter Dimov <pdimov_at_[hidden]> wrote:
>> E. Gladyshev wrote:
>>> 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?
Exception safety guarantees state what happens if an exception is thrown in
a correct program, just like 2 + 3 only yields 5 on good hardware.
For example, given the hypothetical function
int f(int x);
// Requires: x >= 0
// Returns: a number r such that r * r == x
// Throws: invalid_argument if no such number exists
if you call f(5) and get an exception, the ES guarantee (implicit strong in
this case) applies. If you call f(-11), you get "undefined behavior" and
nothing is guaranteed, whether an exception is thrown or not. If you call
f(16) and get an exception (or a return value other than 4), this is
obviously a bug in f and the specification cannot be trusted, so the
behavior is undefined, too (because the given definition is incorrect).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk