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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
