4 ms·
From a reasoning perspective throwing an exception is the same as returning from a function. If you want to reason about code which potentially throws an except
by fmap 10y ago
From a reasoning perspective throwing an exception is the same as returning from a function. If you want to reason about code which potentially throws an exception you have to keep track of a separate exception post condition.
If you compile exception handling to separate return addresses this becomes rather obvious. In this case your control flow also stays reducible, which is commonly taken to mean "simple to reason about", and is very different from the kind of control flow that you can introduce using goto statements.
I think the main problems with exception handling are cultural and psychological. Culturally we don't insist on proper documentation for exceptions. At best you'll see documentation for the functions throwing exceptions directly, but almost never for the functions using them a few levels up the stack... The situation is even worse with higher order functions for which people almost never document the exception behavior. Psychologically most people seem to ignore all but the most obvious exceptional cases. We really have to force ourselves to notice everything that could go wrong and to take a step back and rethink our designs if this question doesn't have a simple answer...
- mondoshawan 10y agoDocumenting and mentally reasoning about exceptions is only half the problem. The other half is scaling this discipline inside individual teams and scaling it out beyond as well. As a for instance, I can give instruction to my team to document exceptions when they are used, but during code review, I cannot guarantee that my engineers are being thorough enough to also document exceptions thrown deeper in the stack -- especially when dealing with a very large pre-existing codebase they didn't write and only have a passing familiarity with.
- baq 10y agodocumenting every possible exception becomes next to impossible if any function above in the stack decides to throw a new kind after a code change...
- marcosdumay 10y agoEven Java had to create some escape valve for its explicit exceptions, just because there was a huge set of them that could appear literally anywhere. But then, exchanging that for return values does not make your life easier in any way. It just means you will have to write redundant tests, and will have a flow that is exactly equivalent to the exceptions flow, after you simplify the redundancy down. You can have your compiler or IDE making the list of possible exceptions for you. But that list is always too big to reason about anyway, and for high order functions, it may be the entire set of exceptions available for your code and some more the it can't discover at compile time. Haskell has tried a different take on the problem with error monads. It's clean, simple, and does not solve the entire problem. So, it also has exceptions, and they are even worse there than at the imperative languages, because everything is high order. I think people are entirely justified in ignoring the problem and moving on. Unless you want to dedicate yourself into research, there is not a clear path to solve it.