How to reason about exceptions
I am not here to tell you whether exceptions are better or not. This could honestly be called how to reason about error handling as most of the content can be applied to any error handling scheme you use, but I’d like to focus on exceptions as they are my favorite ways to handle errors and hopefully shed some light on how to be able to reason codebases which uses exceptions. There are a lot of resources about how to use exceptions, but not a lot on how to reason about them beyond the basics of what occurs when you throw them. This post does assume you have basic understanding of how exceptions work.
Let’s assume that we’re in a codebase that only uses exceptions for error handling, even more horrifying, let’s assume we only have access to unchecked exceptions. How can we possibly tell what can error? How do we reason about the function’s control flow? Actually, can we reason about anything in the codebase? We can, but first, let’s have a quick rundown of the semantics of error handling.
Detection is to detect some erroneous behaviour and report it. Let’s say it reports an error object. Propagation begins the moment we leave the current stack frame with the error object. If we handle the error within the same stack frame the error was detected in, propagation is skipped.
