On Fri, 4 Jul 2008, Bulat Ziganshin wrote:
Hello Ian,
Friday, July 4, 2008, 5:29:24 PM, you wrote:
This is a proposal to replace the current exception mechanism in the base library with extensible exceptions.
extensible exceptions, records and syntax are my favorite missing-in-haskell-garden pets, so my +1000
In Modula-3 you have to add the exceptions that can be raised to a PROCEDURE header. Java has adopted this mechanism. http://www.cs.sfu.ca/~cameron/Teaching/383/Exceptions.html I think that's a very clean and safe approach and it can be easily adopted in Haskell, although not as a drop-in replacement. If I call an IO action I want to know precisely what exceptions or possible extensions I have to expect. We can nicely formulate this in Haskell. Say, pure IO never throws exceptions and exceptions are implemented as exceptional return values, like readFile :: IO (Either IOError String) Instead of Either we should use a specific datatype, say data ExceptionalResult e a = Success a | Exception e and (IO (ExceptionalResult IOError String)) could be wrapped in a monad transformer like ErrorT (ErrorT is not the right name, because it is not intended to handle 'error's): ExceptionalAction IOError IO String Now 'catch' gets the signature: catch :: ExceptionalAction e0 m a -> (e0 -> ExceptionalAction e1 m a) -> ExceptionalAction e1 m a E.g. a routine that wants to call system routines with IOError exceptions can wrap IOError in a custom datatype like data MyException = TooLazyToday | IOError IOError and a catch call would look like catch m (\e -> case e of TooLazyToday -> return "bla" IOError err -> throw err)