Proposal: Extensible exceptions

[Ian Lynagh]

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.


Thanks
Ian