Proposal: Extensible exceptions
isaacdupree at charter.net
Sat Jul 19 19:08:51 EDT 2008
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 "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).
More information about the Libraries