They're good for exceptional situations where foundamental, core assumptions are broken for some reason.
In such scenario there's no error recovery, software is expected to shutdown and raise loud error.
In such scenario there's no error recovery, software is expected to shutdown and raise loud error.
... That seems like a pretty accurate description of how exception handling mechanisms are implemented under the hood. :)
And - very often, you would _not_ shut down. Examples:
* Failure/error in an individual operation or action does not invalidate all others in the set of stuff to be done.
* Failure/error regarding the interaction with one user does not mean the interaction with other users also has to fail.
* Some things can be retried after failing, and may succeed later: I/O; things involving resource use, etc.
* Some actions have more than one way to perform them, with the calling code not being able to know apriori whether all of them are appropriate. So, it tries one of them, if it fails tries another etc.
No, that's what assertions or contracts are for.
Most exceptions are supposed to be handled. The alternative to exceptions in C++ are error codes and `std::expected::. They are used for errors that are expected to happen (even if they may be exceptional). You just shouldn't use exceptions for control flow. (I'm looking at you, Python :)
I like the idea of an exception as a way to blow out of the current context in order for something else to catch it and handle in a generic manner. I don’t like the idea of an exception to hide errors or for conditional logic because you have to know what is handling it all. Much easier to handle it there and then, or use a type safe equivalent (like a maybe or either monad) or just blow that shit up as soon as you can’t recover from the unexpected.