IME, exception-handling works well as an error-handling mechanism where a very simple policy is being applied for a very wide range of error cases. Example: 0.

IME, exception-handling works well as an error-handling mechanism where a very simple policy is being applied for a very wide range of error cases. Example: 0.0001% of the total data in this analysis pipeline is malformed for reasons a-z and A-K (and counting). Don't care; throw out that one datum and continue. Some web request went badly. We're concerned about leaking internal details to the caller. So, you reply with a generic error code, log something about it for operator investigation, and make sure that any other state changes were rolled back along the way. Condition systems invert that relationship. Its not just a failure to open a file, but a failure to open one specific file for a specific use case in the pipline out of several that are needed in total. In a condition system, the caller needs to set up a handler for each one of those use cases, and possibly bind some additional discriminating information to the arguments to disambiguate them on the way back up the stack. If a reasonable fallback policy is available, I'd much rather partition the pipeline up such that the fallbacks are applied on a case-by-case basis in the control flow of the caller. Idiomatic Python code does this all the time with exceptions. Idiomatic code with Optional types does so, too. Both methods are well-suited to the task, and I have never found myself wishing for a condition system when using them.