CppCon 2014: Jon Kalb 'Exception-Safe Code, Part III'

—
--
Are you 100% confident that your code is exception-safe?

Safe usage of exceptions is a non-trivial problem that the industry has struggled with for the better part of two decades. If you have fear, uncertainty, or doubt about exception safety or just want to see the best practices for using exceptions in C++ and/or C++11/14, this session is for you. We'll start with "What is the problem we are trying to solve?" and discuss alternatives, acknowledge the challenges associated with exception usage, and cover some well-meaning but misguided attempts at safety. I will then present a set of guidelines that are the basis for safe exception usage and solid implementation techniques, including how to transition from an exception-unsafe legacy code base.

When we are finished you will know how to produce code that is easier to write, easier to understand, faster, and 100% robust in the face of exceptions.
--
Jon has been programming in C++ for over twenty years. During the last two decades he has written C++ for Apple, Dow Chemical, Intuit, Lotus, Microsoft, Netscape, Sun, Yahoo! and some less well­‐known companies. He taught C++ in the graduate school at Golden Gate University for three years and is a founding moderator of the Boost‐User and Boost‐Interest mailing lists.

Jon is active in the Silicon Valley chapter of the ACCU and programs the C++ track at the Silicon Valley Code Camp.

--
*-----*

[MagnificentImbecil]

I wish to thank you with all of my heart !! So full of learnings these presentations have been !! And finally I know what RAII stands for !!

[MagnificentImbecil]

23:10 -- I believe that instead of adding a specialisation of `std::swap` (obviously in the `std` namespace), we can add a `swap` function in our own namespace.

After all, a type `T` is a model of the Swappable concept if-and-only-if the users can swap the contents of two objects of type `T` by writing `{ using std::swap;;swap (object1, object2); }`. The unqualified call to `swap` is going to also look into the namespace of `T` for an appropriate `swap` function. Then it is going to perform overload resolution between that function and `std::swap <...>` and maybe other functions called `swap`. If our function is a perfect match, it is going to be selected by overload resolution.

Then we have a consistent recommendation for both classes and class templates: we define our non-member `swap` function or function template in the same namespace as our class or class template (and never mess with the `std` namespace).

[MagnificentImbecil]

30:05 -- Slide 157 -- FWMOIW (For Whatever My Opinion Is Worth), I agree with the recommendation to avoid `noexcept` in most other places, lest users start relying on the function being `noexcept` and it becomes difficult later to change the implementation.

Exceptions are normally non-intrusive (for the layers of code in-between the `throw` and the `catch` -- let us keep them non-intrusive.

[zhulikkulik]

Exceptional presentation, thank you!
I will probably have to try watching it again to catch all nuances 😁

[MagnificentImbecil]

30:04 -- Slide 154 -- Deallocation functions should also never throw (given correct input). Also: on ABI boundaries, where the caller and the callee do not both use C++ or C++-with-exceptions or the same version of the same toolchain, we should prevent exceptions from propagating.

[LordEvrey]

The only useful reason to enforce deriving von std::exception is that the default terminate handler will print std::exception::what, as it recognises subtypes of std::exception.

[JonKalb]

Michi, it's intentionally not a rule, but not because it's a bad idea.

Here's why. If you can be guaranteed that every library you are using *and any library you might ever use in the future* follows the rule then you can avoid writing a catch-all handler in main().

But it seems to me that you can't know this and adding a catch-all handler to main() is pretty painless, so you really should put a catch all handler in main().

And if you are doing that anyway, do we really need the rule?

[MichiHenning]

Is that really the only useful thing? If libraries throw things that don't derive from std::exception, I have to write additional catch handler(s) for all root exception types thrown by all libraries I call into.

[frithjofhudepohl]

i always though Scott Meyers was at times a little bit arrogant in his talks... But Scott really delivers content and quite brilliantly. But this guy really made me think if or if not watch his crap till the end. There are a few useful thoughts here i think, but, oh my, his attitude...