FAQ: What does it mean that exceptions separate the "good path" (or "happy path") from the "bad path"? ←(in the new Super-FAQ)
It's in Section: Exceptions and error handling:
- FAQ: What are some ways try / catch / throw can improve software quality?
- FAQ: Do the benefits of exceptions show up with tiny programs?
- FAQ: How do exceptions simplify my function return type and parameter types?
- FAQ: Do exceptions separate the "happy path" from the "bad path"? (this FAQ)
- FAQ: Okay, so you're saying exception handling is easy and simple, right?
- FAQ: Mindset and discipline for exception handling?
- FAQ: I have too many try blocks; what can I do about it?
- FAQ: How can I handle a constructor that fails?
- FAQ: How can I handle a destructor that fails?
- FAQ: How should I handle resources if my constructors may throw exceptions?
- FAQ: How to prevent memory leaks when exceptions are thrown?
- FAQ: What should I throw?
- FAQ: What should I catch?
- FAQ: But MFC seems to encourage the use of catch-by-pointer; should I do the same?
- FAQ: Meaning and use of throw; (without an object)?
- FAQ: How do I throw polymorphically?
- FAQ: When I throw this object, how many times will it be copied?