There are three forms of failure handling currently supported in the C++ standard:
- Anticipated expected failure, which are usually handled with error codes/enums e.g. std:: error_code. This has the compiler emit code directly into the hot path to handle the failure.
- Anticipated unexpected failure, which are usually handled with throws of C++ exceptions. This has the compiler emit failure handling into cold path tables, which are traversed by a runtime routine in the assumed unlikely event of a C++ exception being thrown.
- Unanticipated unexpected failure, where the compiler has quite literally not generated the code to handle such a failure. This presents a unique problem of how to recover from such failure, as the state of parts of the program may be unknowable.
C++ has made much progress on the first two forms of failure handling since its inception in the 1980s. However with respect to the third form, despite multiple unsuccessful attempts by many eminent individuals at big changes, and many successful small improvements tinkering around the edges, in today’s C++ standard we are not particularly dissimilar to where we were in the 4th edition of original Unix in 1973 i.e. exactly as we were when C++ was first begun.
It is long overdue that the C and C++ standards modernise their support for handling of the third form of failure of compiler-unanticipated interruption, better known as signals. This paper proposes a modernisation which from consultation with the various stakeholders involved, this author believes will satisfy C, C++, POSIX and the other major programming languages.