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