[Haskell-cafe] Are there standard idioms for lazy, pure error handling?

[Luke Palmer]

On Sun, Nov 29, 2009 at 11:08 PM, Malcolm Wallace
<malcolm.wallace at cs.york.ac.uk> wrote:
> Are you sure that there can be no error recovery, to continue with events
> after a mal-formed event has been discarded?  In many cases, it is possible.
>  However, if you really want to terminate the stream at the first error, and
> to reflect this in the type, then I guess you can define your own list type:
>
> data ListThenError e a = Cons a (ListThenError e a)
>                       | Error e
>
> Of course this has the disadvantage that then your consumer must change to
> use this type too.

If it is correct, there is no disadvantage.  Using a list when it is
not the appropriate structure will make both the producer and the
consumer code uglier. You might gain a little notational convenience,
but you bubble implicit assumptions, such as an error terminates a
stream, through the code where they can not be checked.

Of course, when you have a stream from which errors can be recovered,
do not use a type that terminates with errors.

Everything cleans up so nicely when your model perfectly captures your problem.

Luke