Comment by tester756
1 day ago
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.
1 day ago
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.
If you're planning on shutting down, what's the fundamental difference between throwing an exception, vs simply complaining loudly and calling exit() ..?
Sometimes it’s useful to handle the exception somewhere near its origin so you can close related resources, lockfiles, etc. without needing a VB6 style “On Error GoTo X” global error handler that has to account for all different contexts under which the exceptional situation might have occurred.
Your process can crash or be killed at any moment anyway. Depending on in-band cleanup is not reliable.
1 reply →
> a VB6 style “On Error GoTo X” global error handler that has to account for all different contexts under which the exceptional situation might have occurred
... That seems like a pretty accurate description of how exception handling mechanisms are implemented under the hood. :)
The code that's throwing an exception typically does not know that the exception catcher will shut anything down.
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.
Yet, if you can only explain an exception using the word ‘exception’ you’re not making any head way.
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.
> They're good for exceptional situations where foundamental, core assumptions are broken for some reason.
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 use asserts for this purpose.