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

[Jonathan Cast]

On Sat, 2009-03-28 at 01:27 +0100, Henning Thielemann wrote:
> 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.)

Hmm, hoogle doesn't know that name.

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

Right.

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

Yi's new parsing library (just finished the paper a couple days ago)
seems quite appropriate to a lazy IO library; for that library, partial
grammars are errors anyway, so the issue doesn't really arise.

If you want IO failure/parsing failure handling in lazy IO, my
preference would be for a separate failure-handling hook (which can
throw an asynchronous exception if needed) rather than for any kind of
synchronous exception mechanism per se.  There's really not much you can
do, except tell the user either `hey, that doesn't look like valid
input!' or `sorry, the other side of the network connection
disappeared', and hope the operator can correct the issue.  I don't
think it's really important to let the input processing (as opposed to
parsing) code handle the situation specifically.

jcc