Talk:Exception safety

message: 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)
replies: text: 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)
replies: text:  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)
replies: text: 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  (taken from Exception handling before that chapter was moved to Exception safety). – Tea2min (talk) 07:50, 4 August 2017 (UTC)
replies: text:  "Anyway, I think the wording definitely could be improved. I think that text was clearer in " - 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)

text:  "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)
thread_title:  no-throw guarantee