Duncan Coutts duncan.coutts at
Sun Nov 2 09:44:12 EST 2008

On Sat, 2008-11-01 at 19:09 -0700, Sigbjorn Finne wrote:
> (+1) to that request - what is the "best practices" for portable exception
> handling code that straddles version 6.10, i.e. that compiles with compilers
> at either side with minimal fuss? I can imagine a couple of 
> alternatives, but
> would like to hear what others are doing here.

As far as I know there is no nice easy way to be compatible with both
models. There's no subset you can stick to that works with both.

In libraries like Cabal and other libs we've done things like:

catchIO :: IO a -> (Exception.IOException -> IO a) -> IO a
#ifdef BASE4
catchIO = Exception.catch
catchIO = Exception.catchJust Exception.ioErrors

catchExit :: IO a -> (ExitCode -> IO a) -> IO a
#ifdef BASE4
catchExit = Exception.catch
catchExit = ... etc ...

The point is, the old catch deals with just one exception type, while
the new one works with various kinds of specific exception types. So
you'd need one of these ifdefs for each type of exception you're

The other alternative is to just keep using the base 3 exceptions for a
while and switch next time your lib makes a major api change.

If you need to switch to base 4 for other reasons you can use the
Control.OldExceptions if you don't want to switch to the new exceptions
at the same time.

I don't know much about the extensible-exceptions package, I'll let
someone else explain about that.

I was initially rather annoyed that the api has changed to much that it
was not possible to make code work nicely without using cpp. On the
other hand, the new exceptions api is a good deal nicer to use and is
much more easily extensible. The old dynamic exceptions stuff was
horrible. We used it in gtk2hs to implement the detailed exceptions that
glib/gtk throws, but it constantly confused users. The new api also
encourages you not to do silly things like catching all exceptions,
known and unknown like the previous api did. This is important now that
we have things like ^C being exceptions.


More information about the Glasgow-haskell-users mailing list