[bitc-dev] RFI: BitC exceptions design
swaroop at cs.jhu.edu
Thu Aug 11 13:05:50 EDT 2005
Jonathan S. Shapiro wrote:
> This is a Request For Input.
> For several reasons, I have concluded that we need to declare
> exceptions. Originally I though that we might get away without this, but
> it now seems likely that we cannot.
I agree that we should declare exceptions.
> (defexception oops string)
> (throw (oops "I goofed"))
looks fine. We also need some try and catch.
> However, this raises several questions:
> 1. Should exceptions be able to carry state and/or other content?
> 2. Is an exception a type or a value?
> 3. Is an exception a reference type or a value type?
> If we are going to declare exceptions anyway, then the exception
> declaration declares a reference type and the exception that is thrown
> is an instance of that reference type.
Do we have a necessity to make exceptions first class? If not, we can let
exceptions be a separate type (other than value and reference types).
> Conceptually, I am assuming that the type Exception is an *open* tagged
> union, and that each DEFEXCEPTION declaration declares a new union tag
> and any accompanying fields.
Yes, exception type is extensible and is hence very special. In the
absence of primitives like polymorphic variants, I think we should let it
> 4. Can exceptions sensibly be polymorphic?
I think exceptions should not be able to carry polymorphic arguments. At
most, they can be monomorphic anyway, so it is better to make them
carry only monotype arguments.
> So: Can anyone offer an example where polymorphic exceptions are
> actually useful?
As you have previously said, it is not possible to achieve this.
> 4. If exceptions are NOT polymorphic, then no monomorphism restriction
> is induced on the catch block. I'm not sure yet, but this *may* mean
> that it is possible to have exceptions that do not trigger a value
I tried this out:
Objective Caml version 3.08.3
# exception Xn of int;;
exception Xn of int
# try raise (Xn 10) with Xn n -> function x -> x;;
- : '_a -> '_a = <fun>
I am not really sure why this needs to be restricted.
More information about the bitc-dev