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
More information about the Haskell-prime