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

[Henning Thielemann]

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