
On Fri, 27 Mar 2009, Donn Cave wrote:
Quoth Jonathan Cast
, An `error' is any condition where the correct response is for the programmer to change the source code :)
That's a broad category, that overlaps with conditions where there are one or more correct responses for the original program as well.
If I throw exceptions within the type system, using IO or whatever, and at some later time observe that I have caught one that would have been better handled closer to its source, for example. I've already technically satisfied my requirement, since everything is in an exception monad, but the exception is still a bug.
I don't understand this one.
Or if I catch an non-IO error using Control.Exception.catch (if I were using ghc), and take advantage of the opportunity to release locks, post various notices, etc. - I evidently have a bug, but I also may need to have a programmed response for it.
The usual example against clear separation of exceptions and errors is the web server which catches 'error's in order to keep running. However, the web server starts its parts as threads, and whenever one thread runs into an 'error', it is terminated, just like an external shell program, that terminates with a segmentation fault. So, yes an error might be turned into an exception, but these are rare cases. In general it is hard or impossible to correctly clean up after an error, because the error occured due to something that you as programmer didn't respect. The "error handler" could well make things worse by freeing memory that is already deallocated and so on.