CppCon 2015: Fedor Pikus “The Unexceptional Exceptions'

—
—
The main goal of this class is not to teach how to use exceptions - it's not that hard, and we will go over the basics at the start of the class. The main goal is to teach to not be afraid to use exceptions, and also not to be awed by them. We will spend few minutes on the basic syntax and semantics of exceptions, as well as their interaction with other parts of the language. Then we get to the real issue: the error handling. It is important to understand that errors, or exceptional cases, do not need to be handled by exceptions. Exceptions are just a tool that provides one way of coding the error handling, and it’s not even a very good one: overly focusing on exception handling, as opposed to error handling, often leads to code that is both buggy and hard to read and maintain. My goal is to show that the best approach to error handling involves very light explicit use of exceptions. The emphasis is put on maintaining program invariants and avoiding the undefined behavior, something all programs need to do at all times, with or without errors. Thus, a well-written program should have very little error handling code, and only a part of that explicitly deals with exceptions. This understanding is particularly important for programmers who have to deal with the “we don’t use exceptions here” mindset, or want to use exceptions for handling errors in their part of the larger legacy system. Once you understand (small) the role exceptions play in the real problem of error handling, it becomes quite obvious how to start using exceptions in a small part of a larger system without disturbing the rest of it, or even how to write very “exception-like” code without actually using exceptions. Most importantly, the exceptions are completely demystified.
—
Fedor G Pikus is a Chief Engineering Scientist in the Design to Silicon division of Mentor Graphics Corp. His earlier positions included a Senior Software Engineer at Google, and a Chief Software Architect for Calibre PERC, LVS, DFM at Mentor Graphics. He joined Mentor Graphics in 1998 when he made a switch from academic research in computational physics to software industry. His responsibilities as a Chief Scientist include planning long-term technical direction of Calibre products, directing and training the engineers who work on these products, design and architecture of the software, and research in new design and software technologies. Fedor has over 25 patents and over 90 papers and conference presentations on physics, EDA, software design, and C++ language.
—

*-----*
*-----*

[KhalilEstell]

This is probably one of my favorite talks regarding exceptions and how to handle errors in code. Honestly, the slide about "what catch is not meant to do" really changed the way I'm going to approach error handling in my code.

[Spiderboydk]

Yes there are. The myth is that exceptions objectively always have bad performance, which isn't true. For example exceptions incur no runtime speed cost as long as exceptions aren't thrown (which should be a rare occurence anyway).

[planetis-m]

43:35 who deallocates the old buffer then?

[kronek]

Doesn't 10:51 "Type of the object to throw is determined at compile time" contradict with 11:21? The dynamic type of throw_if_trouble is not known until run-time and so is which virtual function raise() is to be called. Let me know if I'm mis-understanding something

[athosliu]

45'42" the codes are wrong, isn't it?
- CG shall be construct as CG(dest, dest + size*2)
- and sucess() body shall be release=true;

[lapinrigolo]

Every other commenter in this thread seems to contradict the previous one.

[Spiderboydk]

I think he probably should have put a bit more focus on debunking the performance myths of exceptions. That seems to be the greatest concern of those, who are wary of exceptions.

[soulstudiosmusic]

Good overview talk for exceptions. Thanks.

[llothar]

And this is just a wrong statement.

There is a cost of exceptions even if never thrown because the code generator can't apply a lot of optimizations. And all of them involve storing values back into main memory access to allow stack unwinding. This is one of the most precious operation when you have L3 cache misses or cache coherency line requests that can costs thousands of clock cycles.

[llothar]

They are no myths. What exceptions can do to optimizing code generators is terrible.