Talk:Exception safety

Untitled

This should be really article named exception safety (C++). The term Abrahams guarantees is not that known and not that used and not really enlightening a reader. Pavel Vozenilek 22:46, 15 January 2006 (UTC)

Exception safety redirects to Exception handling which seems to be a bit of a howler.

"Abrahams guarantees" was used in (one or more of) Sutter's books but agreed not in wide currency. Seems like we need to undo the direct and move the page. Though that leaves a gap - what do people mean by "exception safety" in languages other than C++?

"what do people mean by "exception safety" in languages other than C++?" In language with exceptions like C# or Java? Exactly the same thing (they even acquired a primitive RAII with the C# using/Java try-with-resource statements). In languages without exceptions, like C... I'd argue it means exactly the same thing, because you have multiple ways to interrupt the normal, expected flow of execution of code (break, longjmp, etc.). My take on this is that this concept is badly named: It should be called "interruption safety" Paercebal (talk) 18:49, 10 February 2018 (UTC)

no-throw guarantee

Why is this described as "Very difficult or impossible to implement"?? Almost all of the commercial C++ projects that I've worked on (a dozen years, half a dozen companies) have used the no-throw guarantee in their entire code-bases. It's extremely common. On many (non-desktop) platforms, it's actually highly recommended to disable exception support in your compiler as it negatively affects code-generation, which forces the no-throw guarantee on your project in one fell swoop. 27.253.76.253 (talk) 13:31, 7 April 2017 (UTC)

Even if a function uses a memory allocation function that potentially throws, it can catch the exception internally, such that the external world never sees this. I'm equally confused about this claim. Marking as dubious. — MaxEnt 01:40, 18 July 2017 (UTC)

CppCon 2014: Jon Kalb "Exception-Safe Code, Part II" at 45m30: nothrow functions never emit an exception, anything internal is fair game (including destructors). Slide at 47m confirms what was spoken. — MaxEnt 03:55, 18 July 2017 (UTC)

This is in the context of the given example of adding an element to an instance of a smart array type like std::vector in C++, say by calling push_back. Memory allocation can fail, and so this operation can fail, too, and the standard definition of push_back doesn't define an error channel other than throwing an exception, and in this sense a no-throw implementation of push_back is virtually impossible. Of course, there are ways work around this, e.g. by reserving the necessary space before calling push_back and catching any exceptions that might be thrown there. Anyway, I think the wording definitely could be improved. I think that text was clearer in an older version of that chapter (taken from Exception handling before that chapter was moved to Exception safety). – Tea2min (talk) 07:50, 4 August 2017 (UTC)

"Anyway, I think the wording definitely could be improved. I think that text was clearer in an older version of that chapter" - Actually, no, the wording is wrong. There is a difference between a function that doesn't throw an exception, and a function that doesn't throw an exception per se but is transparent to exceptions thrown by other functions it calls (usually callbacks). The second case is a "transparent" function and it doesn't offer the "nothrow" guarantee (or offers it conditionally), while the first does. Paercebal (talk) 18:44, 10 February 2018 (UTC)

"Very difficult or impossible to implement if using the standard library" This assertion is wrong, because is it unrelated to the Standard Library, or even exceptions. This level was called Nothrow/Nofail by Herb Sutter for a reason. Please read again the description of Nothrow above, and you'll see the constraint is to have a function that doesn't fail. And it is very difficult to have functions that don't fail in any code, inside or outside the Standard Library. In fact, a C function is not guaranteed to be "nothrow", despite being "noexcept" (see what I did, there?). To me this should be rewritten as "Very difficult or impossible to implement in the current example since memory allocation can fail." Paercebal (talk) 18:44, 10 February 2018 (UTC)