Proposal: Extensible exceptions

[Henning Thielemann]

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)