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

[John Lato]

On Sat, Mar 28, 2009 at 9:49 PM, Henning Thielemann
<lemming at henning-thielemann.de> wrote:
>
> On Sat, 28 Mar 2009, John Lato wrote:
>
>>> From: Donn Cave <donn at avvanta.com>
>>>
>>> I have never felt that I really understood that one.
>>
>> Honestly, me neither, until recently.  I'm only barely starting to
>> understand it, and I do think there's a great deal of overlap.  Even
>> if an error is a bug that can be fixed by the programmer, certain
>> exceptional situations can also be fixed by the programmer by handling
>> the exception, even if they can't be detected in advance.
>
> For example?

A file not being written because of a permissions error.  This can't
be detected in advance due to effects from other processes, but it's a
predictable enough exception that the programmer should handle it for
IO.  Handling a DivByZero exception when doing IO, however, is very
likely wrong.

>
> Btw. not handling an exception is an error.

Agreed generally.  But some exceptions are likely in given contexts,
others are not.  I don't think it's necessary to handle every possible
exception, just the ones that are likely and predictable for a given
activity.  Excluding generic "The impossible happened, file a bug
report" handlers.

>
>>> I will also guess if the file is unreadable because of an external
>>> I/O problem like no read access to file or filesystem, you would
>>> similarly expect this to be treated like that - I mean, ideally, e.g.,
>>> hGetLine :: Handle -> IO (Either IOError String)
>>
>> Not necessarily, but possibly.  The big difference, of course, is that
>> decoding can be a pure operation, while reading never is.
>>
>> I personally wouldn't mind if hGetLine had the type you give.  The way
>> I see it, there are two advantages to exceptions in this case.  The
>> first is that it's very easy for exceptions to trickle up and be
>> handled at a higher level.  The second 'advantage' is that the
>> programmer doesn't need to explicitly handle exceptions, whereas an
>> Either would require at least a pattern match to use the resulting
>> value.
>
>  I'm afraid there is some confusion about what we mean with "exception". Do
> you only mean the thing that is silently handled in the IO monad?

Yes.  I was comparing exceptions as they exist in IO in Haskell to the
proposed hGetLine type.

> Is Left in
> Either an exception for you, too?

No.

> In explicit-exception I call the
> corresponding constructor Exception, because that's what it is used for.
>  I like to call all those things exceptions, because they are intended for
> the same purpose: Signalling exceptional situations that we cannot avoid in
> advance but that must be handled when they occur. You can use IO and its
> exceptions, I call them IO exceptions. It does not show in its types that
> and which exceptions can occur. Some people consider this an advantage, I
> consider this an disadvantage.

I remain undecided on this for the moment.  I should take another look
at explicit-exception now that I understand its intent better.

John