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