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

[Henning Thielemann]

On Sat, 28 Mar 2009, Ketil Malde wrote:

> Jonathan Cast <jonathanccast at fastmail.fm> writes:
>
>>> 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 often write parsers that either run successfully, or abort with an
> exception.  I could of course return an Either type, but that would
> mean the whole file would need to be parsed before any results could
> be returned at all - which is a showstopper for streaming processing
> of large files.

If you need a lazy parser with error reporting, I suggest 
Control.Monad.Exception.Asynchronous from the explicit-exception package.

> Since at least my files are typically machine generated, a parse error
> is either a programmer error in my parser, a programmer error in the
> generating program, or an operator error (viz. the user running the
> program on a completely different file type).

That's no excuse. You can never rely on proper file formatting since the 
user alter the file while you process it, delete it, or remove the disk it 
is stored on.