Error Handling

[Mark Carroll]

On Fri, 13 Dec 2002, Fergus Henderson wrote:
(snip)
> and [slightly] reduced need to use Monads would be outweighed by the
> drawbacks mentioned above, i.e. code bloat and compiler complexity.)

Ah - that's the impression I got from your earlier reply, too.

(snip)
> time-outs or user interrupts.  But if `choose' is only catching
> exceptions raised by explicit calls to "throw" or "error", then
> I think it would be semantically OK, wouldn't it?
(snip)

That would actually be fine - I hadn't been hoping to catch errors that
were things like user interrupts, which sound like they should be monadic
anyway - just things explicitly thrown as you suggest. Admittedly, that is
a rather important point that I should have made - I hadn't actually
thought about errors caused by other stuff going on in the system and I
completely agree that they should be wrapped in monads.

Basically I was just wanting to replace some of the nastiness I have in
code that passes two-tuples of (result, errors) around and has conditional
statements to deal with backing up the functional call chain to deal with
"error conditions". What the code is doing can safely be done completely
without monads so I didn't want any monads to be in the top-level type
signature: all the "errors" involved are all things that were noticed in
normal computation by matching "otherwise" in a guard and whatever, not IO
or anything.

-- Mark