On Sat, Mar 28, 2009 at 9:49 PM, Henning Thielemann
On Sat, 28 Mar 2009, John Lato wrote:
From: Donn Cave
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