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 <[email protected]>
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
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
