[Haskell-cafe] Re: Exception handling in numeric computations
lemming at henning-thielemann.de
Fri Mar 27 20:32:24 EDT 2009
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.
More information about the Haskell-Cafe