Ian Lynagh wrote:
On Thu, Jul 17, 2008 at 09:16:36AM -0400, Isaac Dupree wrote:
I'm not entirely happy with this particular sketch of a proposal, but do people think that my initial issue is something to be concerned about at all? (I'd be glad to be disproved :-)
It's hard to say if it'll be a problem in practice - we don't have any experience with writing exception hierarchies.
However, I /think/ that moving from the current proposal to something like your proposal can be done without breaking any existing code, which makes me think we should stick with the simpler design for now to get some experience. It's a big step in the right direction, at least.
let's analyze what might get "baked in" to ghc release: SomeException as basic exception type that the RTS deals with: that part of the proposal, including the Exception class, is pretty flexible and probably what we want, and (probably) necessary to be tied to GHC. It's not advised to use `seq` on SomeException because it probably won't do any good, and it just might throw an exception :-) More of a nuisance (1 `div` 0 :: Int). Int is likely in base library that can't be upgraded. If so, DivZeroError (in whatever form) has to be defined there too, including its whole slice of the hierarchy. Actually, pattern-match errors are a better example, since it's the compiler's job to insert them. Probably same for RTS exceptions like StackOverflow (if we have any). If we refactor the hierarchy then (just as we are suffering now) we have redundancy issues when viewing it in the old way vs. the new way. I'm not sure whether it's worse or better when changing just part of the hierarchy to work differently. It doesn't look that painful to have different interfaces yet... anyway I propose something like ImplementationException --> CompileTimeException --mostly pattern-match failure --> RunTimeException and everything else can be upgraded? Not sure if those are good names, and where to define numerical exceptions (while accomodating alternate numeric-preludes as best we can). Any idea how much of 'base' we'll be able to shrink away (or more importantly, whether it's so closely tied to the ghc-version that it might not be practical to make upgraded versions that work with older ghc?) -Isaac