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).