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

John Lato jwlato at gmail.com
Fri Mar 27 21:41:20 EDT 2009


> From: Donn Cave <donn at avvanta.com>
> Quoth John Lato <jwlato at gmail.com>,
>
>> An exception is caused by some sort of interaction with the run-time
>> system (frequently a hardware issue).  The programmer typically can't
>> check for these in advance, but can only attempt to recover after
>> they've happened.
>>
>> An error is some sort of bug that should be fixed by the programmer.
>
> 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.

In general I would say that I agree with JCC's responses.

>
> What about invalid inputs?  Say someone encounters a disk full error,
> and the resulting partly written file is now unreadable data for its
> intended application because of an invalid file encoding?  Is that
> an exception, or a bug that should be fixed?
>
> My guess is that you'll say it's a bug, i.e., that application's
> file decoding result should be an Either type that anticipates that
> the file encoding may be invalid.

Not necessarily.  I would be satisfied with a Maybe :)  I've
encountered malformed data frequently enough that any decoders I write
(and I have done so recently) would anticipate invalid data.

>
> 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.

John


More information about the Haskell-Cafe mailing list