CppCon 2019: Ben Saks “Back to Basics: Exception Handling and Exception Safety”

—
—
—
Exception handling (EH) is a powerful tool for dealing with errors. Using EH effectively can produce code that is simpler, more readable, and more robust than you can get with alternative mechanisms. In this session, we will explain the purpose of EH by contrasting it with the most common alternative, function return codes. We will show you the preferred techniques for throwing and catching exceptions, including which types of objects to throw, when to throw them, and how to catch them. We will describe the different levels of exception safety guarantees and demonstrate techniques like RAII that will help you write functions that provide those guarantees. We will illustrate how to write exception-neutral code that allows you to use EH without creating additional failure points.
—
Ben Saks
Chief Engineer, Saks & Associates
—

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

[imanhn]

Thanks Ben. some complementary comments for future seekers: destructors are being called in reverse order cause local variables are in stack here. build-in types don’t throw cause they come from C which doesn’t have EH.

[MrFedX]

Thanks for a great informative talk! Covering not only how exceptions work and propagate but also a crash course in how to write code with exceptions in under an hour is not a easy task, but Ben made it look easy.

[xealit]

In a Back to Basics talk like that, it would be really beneficial to mention _how_ exceptions actually work. I.e. how stack unwinding works. So that the programmers do know what is happening and what are the effects on performance.

[VoidloniXaarii]

Thank you for this insightful point of view of things!

[greenfloatingtoad]

Doesn't the logic for making swap nothrow also apply to move constructors?

[pavankumar-zhml]

Did anyone find slides in the github ?

[User-cvee]

Would the local variable and swap idiom construct the object twice or does the compiler optimize those away?

[zdnuijbsodfteu]

the problem with classic example of RAII and C++ 31:30 is destructor noexcept /~file() noexcept;// reason for which is 42:20 /

is that writes almost always buffered and error for write may be reported in fclose.
so destructor should somehow report error of fclose, and that part makes whole example stupid.


" The fclose() function shall fail if:

[EAGAIN]
[CX] [Option Start] The O_NONBLOCK flag is set for the file descriptor underlying stream and the thread would be delayed in the write operation. [Option End]
[EBADF]
[CX] [Option Start] The file descriptor underlying stream is not valid. [Option End]
[EFBIG]
[CX] [Option Start] An attempt was made to write a file that exceeds the maximum file size. [Option End]
[EFBIG]
[XSI] [Option Start] An attempt was made to write a file that exceeds the process' file size limit. [Option End]
[EFBIG]
[CX] [Option Start] The file is a regular file and an attempt was made to write at or beyond the offset maximum associated with the corresponding stream. [Option End]
[EINTR]
[CX] [Option Start] The fclose() function was interrupted by a signal. [Option End]
[EIO]
[CX] [Option Start] The process is a member of a background process group attempting to write to its controlling terminal, TOSTOP is set, the process is neither ignoring nor blocking SIGTTOU, and the process group of the process is orphaned. This error may also be returned under implementation-defined conditions. [Option End]
[ENOSPC]
[CX] [Option Start] There was no free space remaining on the device containing the file. [Option End]
[EPIPE]
[CX] [Option Start] An attempt is made to write to a pipe or FIFO that is not open for reading by any process. A SIGPIPE signal shall also be sent to the thread. [Option End]

The fclose() function may fail if:
[ENXIO]
[CX] [Option Start] A request was made of a nonexistent device, or the request was outside the capabilities of the device.

"