Jonathan Cast
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. 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). In any case, I want the program execution to halt and report the error as soon as possible. So the difference between an exception or an error type is mainly what you intend to do about it. There's no point in wrapping divisions in Maybe unless you actually are able to do something useful to recover from a zero denominator. -k -- If I haven't seen further, it is by standing in the footprints of giants