Proposal: Extensible exceptions
igloo at earth.li
Mon Jul 7 15:07:42 EDT 2008
On Mon, Jul 07, 2008 at 01:51:11PM -0400, Isaac Dupree wrote:
> I have type issues. Look how inconsistent these types are (I think,
> copied from the patch); some use forall and some use SomeException:
> catchAny :: IO a -> (forall e . Exception e => e -> IO a) -> IO a
> setUncaughtExceptionHandler :: (SomeException -> IO ()) -> IO ()
> getUncaughtExceptionHandler :: IO (SomeException -> IO ())
setUncaughtExceptionHandler/getUncaughtExceptionHandler look like they
are really part of GHC.TopHandler, which is really internal to GHC. That
still needs to be sorted out properly.
> catchAny :: IO a -> (SomeException -> IO a) -> IO a
> Then we don't even need the Rank2Types extension?
I think that's an option, yes, but we do still need
ExistentialQuantification, so I'm not sure how much it buys us.
> Also, according to the extensible exceptions paper p. 4 (footnote 3),
> `catch` with SomeException type should suffice, such that catchAny is
> not needed?
The reason I added catchAny as a separate function was to avoid having
to use a type signature. It's not actually necessary, no.
> Or was it decided that the facility to catch SomeException
> should be separated from the facility to catch any more-specific group
> of exceptions (since that implementation in the paper looks like a bit
> of a hack... or perhaps to warn people that it's a bad idea and should
> use a function with a name that's a big flashing warning)?
That footnote doesn't apply to the final definition of catch, which can
catch SomeException without an ugly-looking hack.
> On a different note: What about strictness?
> data SomeFloatException
> = forall a . (Exception a) => SomeFloatException !a
> deriving Typeable
I don't have a strong opinion, but since we can't force all exceptions
to be "deeply strict", and we can't stop people forgetting to make one
strict, I don't think it buys us much.
More information about the Libraries