In article ,
Dave Abrahams wrote:
>>
>> I have done worse - I have designed and written code that was safe
>> against asynchronous exceptions! Yes, it is WAY beyond the ability of
>> most people, and hell even for the few people who can do it.
>
>So... how did you test (or otherwise prove) its safety?
Eh? This thread is about C++, which is miles away from such rigour. In
the main case, the design was straightforward enough to prove using
pencil and paper though, as always, the devil was in the details and the
coding was tested up to only the usual quality.
> I'm not even
>sure what you mean by "exception-safe" in the context of asynchronous
>exceptions. Since all operations are essentially allowed to throw, I
>think it means you are never allowed to break invariants, even
>momentarily during modifications, because you're never assured of being
>able to complete the process of restoring a broken invariant. Sounds
>like a simple enough world, though I imagine higher-level abstractions
>might be quite hard to build.
Not at all. It means that you must either detect breakage and recover
on next use, or shield temporary breakages with a handler. Yes,
sufficiently evil nested exceptions would lead to an uncorrectable
failure - but, in the design, all detectable failures would be
detected and categorised correctly.
>> C++ exceptions were originally intended to allow for those to be
>> included, but C++11 took a decision to formally exclude them,
>
>Asynchronous exceptions were formally excluded in C++98/03 as well. I'm
>not aware of any changes to the standard language in this area for
>C++11, but even if there were, nothing in C++98/03 allowed "int i = 0;"
>to throw (leaving aside the "resource limits" backdoor which allows
>anything at all).
That's a different point, unless I have missed some peculiar restriction
in the standard. I haven't found any explicit formal exclusion, except
by omission, but I agree that they have been excluded by omission since
day one (as in most other languages).
The wording "intended to allow for those to be included" referred to
an implementation extending the language to allow the clean handling
of system-generated exceptions, which C++11 prevents in enough cases
for it to be fair that it says it forbids them.
Also, there's nothing that forbids them to be thrown in "1.0/3.0",
or in any of the cases where "undefined behaviour" is allowed, which
includes ALL system-generated exceptions.
>> Since the 1960s, many experts have said that all forms of alternate
>> return (of which C++ exceptions are merely one example) are the spawn
>> of the devil. I would not go quite so far, but there is something in
>> that. I generally favour the intermediate state (i.e. supporting
>> trap-diagnose-and-terminate only), which is VASTLY easier to do than
>> trap-recover-and-continue.
>
>Ah, yes, it's much easier, that's true. It's also totally inappropriate
>for many applications.
Unfortunately, most of the cases for which it is inappropriate are also
cases for which the C++ mechanism is worse :-( The point here is that
the critical software-engineering issue is to handle exceptions (in the
general sense) that CANNOT be prevented by better coding - i.e. are
either because they are outside the standard (e.g. floating-point
issues) or externally generated.
>In fairness, it is completely outside the culture for most scientific
>computing applications to use exception handling. Instead, in my
>experience, checkpointing is usually used for recovery of large-scale
>computations, and that may well be the most appropriate choice.
Not in my experience, and I have worked in this area for 40+ years.
Checkpointing is used to solve a different issue.
>> If std::vector WERE exception-safe, I would be more impressed, but
>> I am afraid that it isn't.
>
>Exceeeeeeeeuse me? I spent several years of my life creating a
>well-founded definition of exception-safety, ensuring that in the '98
>standard, the containers, *were* indeed exception-safe, and educating
>the community about it. The containers are generally acknowledged to be
>exception-safe, and people are using the exception-safety guarantees
>successfully.
Before I comment on that, may I see that definition? I have searched
the C++ standard many times and cannot find one. I say below that I
can find the invariants, but they are not a definition.
I have been seriously into software engineering since before that
term came into common use, and the objective is to produce software
that is robust against both internal and external failures.
>> The standard specifies that insertion is, but nothing much else
>
>That's incorrect. All operations are exception-safe, where
>exception-safety is defined as the preservation of invariants: no
>components are allowed to stop working just because an exception was
>thrown.
Grrk. Even ignoring C++03 17.4.3.6, nothing is said about what that
means - to take a simple example, what state is a container left in if a
comparison or copy on the elements throws during a sort? There really
ISN'T much point in saying that a function is 'exception-safe' if it has
no clear meaning - any more than 'thread-safe'.
There is also the generic point that, if the standard does say that
explicitly, it's very well hidden. Yes, I can find the invariants,
but that's a different issue.
>> - and that, in itself, can't be done if the exception is thrown by a
>> destructor following reallocation!
>
>Errors generated by destructors are difficult to deal with in a
>meaningful way, no matter what reporting system you use. They're
>generally not recoverable conditions and thus exceptions are not an
>appropriate way to deal with them.
The first sentence is inarguable. However, why on earth shouldn't
exceptions be an appropriate way to deal with them? They always used to
be, and still are in many languages - note that I am not arguing that
C++ has chosen to use them almost entirely as an alternate return
mechanism - I am asking why they should be inappropriate.
>> Most of the STL allows more-or-less arbitrary data corruption, by the
>> omission of defined behaviour (see 1.3.12 in C++03).
>
>You're linking me to the definition of undefined behavior? I'm quite
>familiar with that, thank you.
It wasn't aimed at you - this is a newsgroup. In my experience, it is
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
