> The problem with a lot of error handling is that it moves beyond that realm and mixes with the logic of the system.
What is the motivation for this? What are the perceived pains that programmers are trying to cure which are not, "cases where you can't tell whether an operation will succeed or not before trying it?"
Most often I think it's due to poor separation of concerns. The programmer is about to push an input down a stack of method calls several layers deep. There's the success condition, the failure condition, then the exception which captures unexpected behavior from the rat's nest of code he just called.
How often can this be addressed with orthogonal finite state machines? (For example: one which embodies whatever business process, and another that embodies errors and failures with IO and the network.)
What is the motivation for this? What are the perceived pains that programmers are trying to cure which are not, "cases where you can't tell whether an operation will succeed or not before trying it?"