Proposal: Extensible exceptions

[Isaac Dupree]

Ian Lynagh wrote:
> On Sat, Jul 19, 2008 at 01:03:56PM -0400, Isaac Dupree wrote:
>> anyway I propose something like
>> ImplementationException
>> --> CompileTimeException  --mostly pattern-match failure
>> --> RunTimeException
> 
> I'm a bit confused - what are you proposing we throw if we have a
> div-by-zero or unhandled-pattern?
> 
> And the name CompileTimeException feels wrong to me.

sorry, half my problem is I have no idea what to call these things.  And 
that I'm not quite as knowledgable as I'd like about these exceptions. 
I'll try again:

There are a few kinds of exceptions that are generated by (e.g.) GHC 
itself: they can't change unless you upgrade GHC, not just because 
they're often in base (or is it ghc-prim now?), but because the compiler 
or RTS refers directly to the type or its structure.  This doesn't 
include division by zero.  That's what I meant by "ImplementationException".

Some of these are ones that, by looking at the syntactical structure of 
your code, you know that cases will be inserted by the compiler that 
throw some sort of error.  I don't remember if there are any ones other 
than pattern-match failure (which is mentioned in Haskell98).  That's 
what I meant by my poorly-named "CompileTimeException".

Others, like stack overflow, are obviously produced by the RTS.  I 
couldn't think of any kind of "ImplementationException" that isn't 
described by either this or the previous category.  That's what I meant 
by RunTimeException.  But I'm not sure anymore if it's such a wise 
category, since it seems some exceptions could enter or leave this 
category (if it's possible to implement throwing them in a library, 
perhaps depending on things like signal handling -- perhaps the RTS had 
to handle some of those, but perhaps it might possibly be separated from 
the RTS too).

-Isaac