exception classifier functions
It's unfortunate that the exception classifier functions differ between GHC and Hugs, even where capabilities overlap. GHC has: ioErrors :: Exception -> Maybe IOError arithExceptions :: Exception -> Maybe ArithException errorCalls :: Exception -> Maybe String dynExceptions :: Exception -> Maybe Dynamic assertions :: Exception -> Maybe String asyncExceptions :: Exception -> Maybe AsyncException userErrors :: Exception -> Maybe String Hugs has: justIoErrors :: Exception -> Maybe IOError justHugsExceptions :: Exception -> Maybe HugsException Would greater commonality be possible? Also, I don't care for the naming scheme for these functions. While use of these functions with `catchJust` and `tryJust` reads very well, other use reads poorly. Names such as `asIOError`, `asArithException`, etc., would better described their interfaces. -- Dean
It's unfortunate that the exception classifier functions differ between GHC and Hugs, even where capabilities overlap.
justIoErrors :: Exception -> Maybe IOError justHugsExceptions :: Exception -> Maybe HugsException
Would greater commonality be possible?
Yes, but it'll take a bunch of work. The big change needed is with the HugsExceptions which are currently little (nothing?) more than a String. To improve on this, we need to go through all the code that raises exceptions and change it around. Not hard but it'll take a while. And sometimes when we port a feature from another system we find that an interface that was easy for the original system to implement doesn't make sense as a more general interface (and, then again, sometimes we find that it's a great design). So, yes, it should be on the list of things to do but I don't think a quick fix is likely to make it in before the release. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
participants (2)
-
Alastair Reid -
Dean Herington