Error Handling

[Alastair Reid]

On Sun, 8 Dec 2002, John Meacham wrote: (snip)
>> throw (userException "foo") + throw (userException "bar")
>> 
>> without defining an evaluation order you cannot know which
>> exepction is to be thrown. catching the exception in the IO monad
>> makes this 'okay'
> (snip)

Mark Carroll <mark@chaos.x-philes.com> writes:
> Would it help if you defined an order over the possible exceptions,
> then if one is thrown you evaluate other parts of the expression to
> see if they also threw one, and return the "first" according to the
> ordering? I still haven't given up my hope for simple exceptions
> without monads. (-:

To do this, we have to actually build the set of all exceptions that
an expression could raise.  This could take quite a while to build
(lots more evaluation may need to be done) and getting any one
exception probably isn't going to be any more useful than the 'random'
choice you get at present.

And even this wouldn't get rid of the monads since the problem monads
deal with is present even if we can't observe the exceptions.  For
example, a simple operation like this:

  choose :: a -> a -> a

which returns its first argument if it can evaluate its argument to
WHNF without raising an exception and returns its 2nd argument
otherwise has severe semantic problems.

--
Alastair Reid                 alastair@reid-consulting-uk.ltd.uk  
Reid Consulting (UK) Limited  http://www.reid-consulting-uk.ltd.uk/alastair/