On Sat, Mar 28, 2009 at 9:49 PM, Henning Thielemann <lemm...@henning-thielemann.de> wrote: > > On Sat, 28 Mar 2009, John Lato wrote: > >>> From: Donn Cave <d...@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?
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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe