[Haskell-cafe] Re: Exception handling in numeric computations
nicolas.pouillard at gmail.com
Sun Mar 29 06:04:43 EDT 2009
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'  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?
More information about the Haskell-Cafe