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

[Henning Thielemann]

On Fri, 27 Mar 2009, Donn Cave wrote:

> Quoth Jonathan Cast <jonathanccast at fastmail.fm>,
>
>> 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.