4 ms·
It’s true that error handling in pure computations tends to be easier than the general case. A lot of the more tricky situations to deal with, IME, tend to be
by Chris_Newton 11y ago
It’s true that error handling in pure computations tends to be easier than the general case.
A lot of the more tricky situations to deal with, IME, tend to be when you have acquired some resource but then for some unexpected reason the resource stops co-operating. Some of the most awkward problems then happen when you can’t even clean up properly at that point, for example by deleting a temporary file or committing a pending transaction on a database, because of the failure, and so you wind up with some externally observable side effects of your program that can’t be fixed.
Another awkward area is running out of system resources such as memory or processes/threads, which many high level programming languages aren’t well equipped to handle gracefully. Lazy languages like Haskell are relatively vulnerable to thunks building up and consuming excessive resources, for example, and while there are practical tools for mitigating that problem up to a point, a lot of the neat theoretical models pretty much go out of the window if you really do hit a hard limit in a production system.
That all said, carrying error information within a monadic framework would be another good example of the kind of systematic error handling strategy I was talking about before.