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

[Donn Cave]

Quoth Henning Thielemann <lemming at henning-thielemann.de>,
> 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.

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