Re: [Haskell-cafe] Re: Exception handling in numeric computations

Quoth Henning Thielemann ,

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.

A lame attempt to demonstrate that "condition where [a] correct response is to change the code" applies to too many cases to be useful. (And that there are no cases where [the only] correct response is to change the code.)

...

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.

But you'd have to weigh that against the consequences of not continuing. I can certainly see the attraction of the exception monad treatment for anticipated errors. It might tend to obscure a central computation for the sake of handling a lot of weird little errors that may never actually be encountered, and doesn't it occasionally have a problem with making things strict that didn't already need to be? but at least it makes it easier to reason about the code in terms that include errors. And I'm using nhc98 lately, so no Control.Exception.catch for me, but if I had it, I'd use it, just like I wear a helmet when I ride my bicycle or motorcycle. Donn