???UNIX signal handling???. Might be worth reminding how little is async-signal-safe, and how to communicate with a signal handler (best is probably "not at all")

E: Error handling

Error handling involves:

• Detecting an error
• Transmitting information about an error to some handler code
• Preserving a valid state of the program
• Avoiding resource leaks

It is not possible to recover from all errors. If recovery from an error is not possible, it is important to quickly "get out" in a well-defined way. A strategy for error handling must be simple, or it becomes a source of even worse errors. Untested and rarely executed error-handling code is itself the source of many bugs.

The rules are designed to help avoid several kinds of errors:

• Type violations (e.g., misuse of unions and casts)
• Resource leaks (including memory leaks)
• Bounds errors
• Lifetime errors (e.g., accessing an object after it has been deleted)
• Complexity errors (logical errors made likely by overly complex expression of ideas)
• Interface errors (e.g., an unexpected value is passed through an interface)

Error-handling rule summary:

• E.1: Develop an error-handling strategy early in a design
• E.2: Throw an exception to signal that a function can't perform its assigned task
• E.3: Use exceptions for error handling only
• E.4: Design your error-handling strategy around invariants
• E.5: Let a constructor establish an invariant, and throw if it cannot
• E.6: Use RAII to prevent leaks
• E.7: State your preconditions
• E.8: State your postconditions

• E.12: Use noexcept when exiting a function because of a throw is impossible or unacceptable
• E.13: Never throw while being the direct owner of an object
• E.14: Use purpose-designed user-defined types as exceptions (not built-in types)
• E.15: Throw by value, catch exceptions from a hierarchy by reference
• E.16: Destructors, deallocation, swap, and exception type copy/move construction must never fail
• E.17: Don't try to catch every exception in every function
• E.18: Minimize the use of explicit try/catch
• E.19: Use a final_action object to express cleanup if no suitable resource handle is available

• E.25: If you can't throw exceptions, simulate RAII for resource management
• E.26: If you can't throw exceptions, consider failing fast
• E.27: If you can't throw exceptions, use error codes systematically
• E.28: Avoid error handling based on global state (e.g. errno)

• E.30: Don't use exception specifications
• E.31: Properly order your catch-clauses