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