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