John, have you seen this? http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Extensible Exceptions Cheers, Simon On 07 April 2006 15:34, John Goerzen wrote:
Hello,
One thing that bugs me about Haskell is that exceptions are not extensible.
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 Haskell?
-- John
On Fri, Apr 07, 2006 at 03:49:40PM +0100, Simon Marlow wrote:
John, have you seen this?
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Extensible Exceptions
Yes, and maybe I'm missing something, but I don't think it quite helps. I followed the link to the example page at: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/browser/HaskellPrim... Down towards the bottom, there is a definition of ArithException, and an example where it is used to throw Control.Exception.DivideByZero. But here's my concern. Let's say that I wanted to, for some reason, create a MultiplyByZero exception. It should be broadly considered an ArithException, and any code that catches an ArithException should be able to catch my MultiplyByZero exception. But the ArithException type is limited to storing errors that are defined by Control.Exception.ArithException. My MultiplyByZero is not defined there, so I am out of luck. The best I could do is define a new MultiplyByZero, and catch it in my own code. But any code that others have written to catch ArithExceptions would be blind to MultiplyByZero. -- John
On Fri, Apr 07, 2006 at 10:00:21AM -0500, John Goerzen wrote:
But here's my concern. Let's say that I wanted to, for some reason, create a MultiplyByZero exception. It should be broadly considered an ArithException, and any code that catches an ArithException should be able to catch my MultiplyByZero exception.
But the ArithException type is limited to storing errors that are defined by Control.Exception.ArithException. My MultiplyByZero is not defined there, so I am out of luck. The best I could do is define a new MultiplyByZero, and catch it in my own code. But any code that others have written to catch ArithExceptions would be blind to MultiplyByZero.
newtype ArithException a = ArithException a data DivideByZero throw (ArithException DivideByZero) your code: data MultiplyByZero throw (ArithException MultiplyByZero) John -- John Meacham - ⑆repetae.net⑆john⑈
participants (3)
-
John Goerzen -
John Meacham -
Simon Marlow