Proposal: Extensible exceptions
marlowsd at gmail.com
Mon Jul 21 07:01:45 EDT 2008
Isaac Dupree wrote:
> Ian Lynagh wrote:
>> On Sat, Jul 19, 2008 at 01:03:56PM -0400, Isaac Dupree wrote:
>>> anyway I propose something like
>>> --> 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
> 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.
More information about the Libraries