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 #else catchIO = Exception.catchJust Exception.ioErrors #endif catchExit :: IO a -> (ExitCode -> IO a) -> IO a #ifdef BASE4 catchExit = Exception.catch #else catchExit = ... etc ... #endif 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 catching. 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. Duncan _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
