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

[Simon Marlow]

Nicolas Pouillard wrote:
> Excerpts from Henning Thielemann's message of Sat Mar 28 21:49:33 +0100 2009:
>> 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?
>>
>> Btw. not handling an exception is an error.
>>
>>>> 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? Is 
>> Left in Either an exception for you, too? 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. You can use error codes or 
>> Either or even better Exceptional from the explicit-exception package, and 
>> Haskell is strong enough to treat these like exceptions in 
>> C++/Java/Modula-3 etc. because you can use their monad transformer 
>> variants ErrorT and ExceptionalT respectively. Those monad transformers 
>> allow automatical termination of a series of actions once an exceptional 
>> result is obtained. But since ErrorT and ExceptionalT are burned into the 
>> types, you cannot miss to handle them.
>>   So the most convenient type for hGetLine would be
>>     hGetLine :: Handle -> ErrorT IOError IO String
> 
> By reading the documentation of 'hGetLine' [1] one can see that this function
> can throw only an EOF exception so why not give it a type like below?
> 
>  hGetLine :: Handle -> ErrorT EOF IO String
> 
> Since one will have to handle the error case it would be better to treat only
> the possible cases, no?

I'm afraid the documentation is incomplete.  hGetLine can also fail because 
e.g. the device it was reading from has been unplugged, or it was reading 
from a network filesystem and the network has gone down.  And there might 
be yet more errors to be invented in the future, so I'm not sure it would 
be a good idea to reflect this level of detail in the type.

Cheers,
	Simon