John Goerzen jgoerzen at complete.org
Fri Apr 7 10:34:05 EDT 2006


One thing that bugs me about Haskell is that exceptions are not

I don't know how to craft a good solution, but perhaps if I explain the
problem well, someone would come up with one.

In a language such as Python or Java, and exception is an object.

Let's consider Python for a quick example.  Python has an IOError
exception.  So if I want to write a handler that deals with IOErrors,
that's easy enough.

Now maybe I want to do something like report socket errors specially.  I
could define a SocketError class that subclasses IOError.  I could take
this further, and define a URLError that subclasses SocketError.

Now the beauty of it is that I can:

 * Have a handler that catches URLErrors only and does nothing special
   with SocketErrors or IOErrors.

 * Have a handler -- perhaps not even mine -- that catches and works
   with IOErrors.  Since SocketError and URLError are descendants of
   IOError, that handler will *automatically* work if I raise a
   SocketError or a URLError.

I can see no such mechanism in Haskell.  Haskell's I/O exceptions have a
certain defined set of errors that they can report, and I can't subclass
them and make them more specific for my purposes if I want.  Ditto for
all the others.

The Dynamic exception support is necessary and good to have, but it also
under-documented and can be complex.  And of course, they still suffer
from the same lack of extensibility

Are there any suggestions on how we might improve this situation in

-- John

More information about the Haskell-prime mailing list