Comment by Mikhail_Edoshin
5 years ago
If you give a name to a mountain, it doesn't affect the mountain, it affects you :)
Joking aside, consider the following case. A function needs to print a series of reports and opens Print Setup. The user changes his mind and presses "Cancel". Now the function cannot continue and needs to stop the planned operations, undo what it has done so far, and return control to the user.
The internal mechanism you're going to use for this will be most likely the same mechanism you use to handle errors. But what you're handling is not an error, at least in the common usage of the word, because nothing erroneous is happening! Everything goes exactly as should and according to the general purpose of the application.
My point is that the current dichotomy of success and failure does not help us to solve the seemingly simple problem of errors.
> The internal mechanism you're going to use for this will be most likely the same mechanism you use to handle errors.
Which is exactly how exceptions work. If you're using RAII or similar pattern in your language there is no separate path for cleaning up errors than from the normal cleanup. That's the point actually. If the user presses cancel or an exception is raised the eventual stack unwinding will undo everything.
If you have a bunch of conditional statements for every possible error, you're actually creating more situations that are unique for errors. You have all these paths to test for. With exceptions there is only the happy path both in the operation and the cleanup.