Proposal: Extensible exceptions

[Simon Marlow]

Isaac Dupree wrote:
> 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).

A useful class of exceptions is those that can occur anywhere, because they 
arise from external stimulus, such as the user pressing Control-C.  We 
currently lump these into "AsyncExceptions", but I'm not wedded to the 
name.  I just thought I'd point out that it's useful to be able to identify 
exceptions from this class.

Cheers,
	Simon