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

[Jonathan Cast]

On Fri, 2009-03-27 at 09:31 -0700, Donn Cave wrote:
> 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.
> 
> 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?

NB: Of course it's a bug: if the disk is full, the partially written
file should be discarded and the previous version retained.  I'm not
going to hold you accountable for Unix's bugs, though.

> My guess is that you'll say it's a bug,

I think you mean `exception' here.

> i.e., that application's
> file decoding result should be an Either type that anticipates that
> the file encoding may be invalid.

This is pretty standard, I thought.  Do people write Haskell file input
methods that are undefined (`throw exceptions') on invalid inputs (e.g.,
do people use read to parse input from users or the file system[1])?

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

IO is an exception monad already.  I don't think there's an objection to
throwing exceptions with throwIO and catching them in IO; my objection,
at least, is to designing your program to throw exceptions from
(ostensibly...) *pure* code and catch those in IO, in a live
environment.

> Does that make sense so far?

jcc

[1] This post should not be taken as an endorsement of the use of the
Read class for any purpose, nor as an endorsement of its continued
existence in the standard library.