Once you give a function a name, it has an operation that's inherent to it.
If you have a function called `Add` that takes 2 parameters and returns the sum of those two numbers. That's the operation. If the web service that you call to perform the sum is down, it cannot return that sum, so that's an failure.
The code that calls this function needs that sum to continue it's operation. If it cannot get that result it cannot produce it's own result and that error needs to be propagated. Maybe the entire program has a purpose that it cannot now be completed and should be aborted.
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.
If you have a function called `Add` that takes 2 parameters and returns the sum of those two numbers. That's the operation. If the web service that you call to perform the sum is down, it cannot return that sum, so that's an failure.
The code that calls this function needs that sum to continue it's operation. If it cannot get that result it cannot produce it's own result and that error needs to be propagated. Maybe the entire program has a purpose that it cannot now be completed and should be aborted.