Proposal: Extensible exceptions

Isaac Dupree isaacdupree at
Mon Jul 7 14:38:26 EDT 2008

Ian Lynagh wrote:
> On Sun, Jul 06, 2008 at 05:32:02PM -0400, Isaac Dupree wrote:
>> I have some trouble 
>> seeing from the patches what the hierarchy of exceptions will be;
> Right, it's a bit obfuscated at the moment, as some of the types are
> where we want them to be (portable modules like Control.Exception) while
> others are where they need to be (GHC.*, to avoid import loops).
> Hopefully we can improve that later.
> Anyway, these patches basically only add the machinery for extensible
> exceptions, but don't define much in the way of a hierarchy themselves.
> All I've done is to break up the old Extension type:
> e.g. for constructors like
>     ArithException ArithException
> the ArithException type is an instance of Exception,
> for constructors like
>     BlockedOnDeadMVar
> I've made a new type
>     data BlockedOnDeadMVar = BlockedOnDeadMVar
> that is an instance of Exception,
> and for constructors like
>     RecConError String
> I've made a new type
>     data RecConError = RecConError String
> that is an instance of Exception,
>> could you describe what the current proposal is for that 
>> hierarchy? (if it exists yet)
> So it doesn't really exist yet. That can be done later, either all at
> once or bit by bit.

Okay, let's see:

As long as it's a single-level hierarchy as described above, we can't 
break anything by adding additional levels in the hierarchy; the only 
difference is that user-added types won't yet be in a new hierarchy 
where they belong, so we should probably think about this (for 6.10, but 
it needn't hold up implementing the exceptions).  On the other hand, the 
proposal can't do multiple inheritance, and that would probably require 
baking certain parts of the hierarchy deep in base-library (whoever has 
to throw a DivZeroError, for example, for Num Int, has to have access to 
that whole part of the hierarchy already.)


More information about the Libraries mailing list