[Haskell-cafe] exceptions vs. Either

[Alastair Reid]

On Monday 02 August 2004 21:09, Evan LaForge wrote:
> Exceptions are convenient [...] 
> [but] an exception will only be thrown when you evaluate t.
>
> So it seems to me that if you are, say, checking input, the options are
> to handle exceptions from the checking code but expect them to come from
> the processing code, or [not use eceptions]
> [...]
> So then, in what contexts are exceptions appropriate in haskell?

I think you're right that exceptions aren't useful for input checking.  You 
really need something that will check all the input at once.  i.e., 
evaluating any part of the checked input causes all input checks to be 
performed.  The easiest way to do this is with a monad or some such - which 
provides you with a more flexible, more controllable error-reporting 
mechanism anyway.

I usually use exceptions when dealing with the outside world where I want to 
protect the outside world from any misbehaviour of the Haskell code.  For 
example, if opening and closing windows or files, controlling a robot, etc., 
I might use the exception catching/propagating to make sure that things are 
shutdown properly when the Haskell program crashes.

In general, if there's a way to make your program bombproof using a 
conventional mechanism (monads, Either, Maybe, etc.), then you should use it 
since it will be easier to reason about and can be more flexible.  But, if 
your program really has to be bombproof and you can't convince yourself that 
it is (e.g., it depends on a library you didn't write), exception handling 
can help a lot.

--
Alastair Reid