This chapter is from the book
This chapter is from the book
This chapter is from the book
Discussion
Report an error (e.g., write throw ) wherever a function detects an error that it cannot resolve itself and that makes it impossible for the function to continue execution. (See Item 70)
Handle an error (e.g., write a catch that doesn't rethrow the same or another exception or emit another kind of error code) in the places that have sufficient knowledge to handle the error, including to enforce boundaries defined in the error policy (e.g., on main and thread mainlines; see Item 62) and to absorb errors in the bodies of destructors and deallocation operations.
Translate an error (e.g., write a catch that does rethrow a different exception or emits another kind of error code) in these circumstances:
- To add higher-level semantic meaning: For example, in a word processing application, Document::Open could accept a low-level unexpected-end-of-file error and translate it to a document-invalid-or-corrupt error, adding semantic information.
- To change the error handling mechanism: For example, in a module that uses exceptions internally but whose C API public boundary reports error codes, a boundary API would catch an exception and emit a corresponding error code that fulfills the module's contract and that the caller can understand.
Code should not accept an error if it doesn't have the context to do something useful about that error. If a function isn't going to handle (or translate, or deliberately absorb) an error itself, it should allow or enable the error to propagate up to a caller who can handle it.