Proposal: Extensible exceptions

[Isaac Dupree]

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