De-fragmenting C++: making exceptions and RTTI more affordable and usable
Recoverable error (definition)
24:50: Start of the definition of whath is an error, and which should be recoverable.
Programming bug is not a recoverable error
27:15: Start of the section
At 28:05:
Out of bounds should never, ever be an error code or an exception. They say "the
standard library does that!". I will show you that we talked to the standard
library folks […] and they agree unanimously "yeah, that’s a problem and we
are going to migrate the standard library away from basically
std::logic_error.
More on 46:31 (TODO: cite). Also, the quote from Duffy (some seconds before).
Taxonomy (28:44)
…
Value semantics (34:01)
So we are doubling down on value semantics.
De-fragmenting C++: making exceptions more affordable and usable
32:58 from Herb Sutter’s talk ("Making exceptions more affordable and usable"):
A quote from a developer working on Midori, an evolution of C# for systems programming.
(With contracts,) 90-something% of the typical uses of exceptions in .NET and Java became preconditions. All of the ArgumentNullException, ArgumentOutOfRangeException, and related types and, more importantly, the manual checks and throws were gone.
-
Precondition violations are bugs, not program-recoverable errors.
-
Don’t report them using error handling (exceptions or codes).
-
Use assertions, contracts or similar instead (report to a human programmer who can fix the bug).
Taxonomy (44:16)
What to use |
Report-to handler |
Handler species |
|
A. Corruption of the state machine (e.g. stack or heap allocation) |
Terminate |
User |
Human |
B. Programming bug (e.g. precondition violation) |
Asserts, log checks, contracts… |
Programmer |
Human |
C. Recoverable error (e.g. host not found, large allocation error) |
Throw exception, error code, etc. |
Calling code |
Code |
Q/A: Exceptions for exceptional moments (1:00:10)
What Could Possibly Go Wrong? A Tale of Expectations and Exceptions
Is this API inconsistent with Herb Sutter’s talk?
GCC manual: Exceptions
In sum, valid C code with exception handling is transformed into a dialect
without exception handling. In detailed steps: all use of the C keywords try,
catch, and throw in the standard library have been permanently replaced with the
pre-processor controlled equivalents spelled try, catch, and
__throw_exception_again. They are defined as follows.
#if __cpp_exceptions # define __try try # define __catch(X) catch(X) # define __throw_exception_again throw #else # define __try if (true) # define __catch(X) if (false) # define __throw_exception_again #endif
In addition, for every object derived from class exception, there exists a corresponding function with C language linkage. An example:
#if __cpp_exceptions
void __throw_bad_exception(void)
{ throw bad_exception(); }
#else
void __throw_bad_exception(void)
{ abort(); }
#endif
Microsoft’s guidelines for exceptions and error handling
To re-read at a different moment, given that some things can be interpreted in different ways, but worth the read, given that it covers the topic of assertions, etc.
Misc
Comments to "C++ Assertion Library" on Reddit
I use asserts and other forms of tests mainly as a help during develop and debugging, not for general error handling. Assert failures during develop are good!
I don’t use asserts for normal error handling in release code when other people may run the software.
This shows that you understand assertions. Of course they are not for error handling. They are used for tracking if all the assumptions about your code hold (invariants, control flow etc).
You turn assertions off, when you’re done with testing these assumptions. They have no use in production code, except of course when the user is your tester.