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

[Henning Thielemann]

Jonathan Cast schrieb:

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

With

  case reads str of
     [(x, "")] -> Just x
     _ -> Nothing

you are safe. (I think it's now available as maybeRead.)

In general, relying on a well-formed input file is an error. However, if
your program detects a format error in file input, it could throw an
exception. But this means that your program must be prepared for these
problems.

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

Actually, I really object to have exception handling built into IO
monad. Especially with extensible-exceptions package you can hide which
kinds of exceptions can occur in a piece of code, which is a bad thing.
When it comes to lazy I/O, which is problematic in itself, it is better
to have explicit exceptions (i.e. IO (Either IOError String)) on top of
exception-free IO. See the recent thread on safe lazy I/O:
   http://www.haskell.org/pipermail/haskell-cafe/2009-March/058205.html