Disjunctive types

[Neal Gafter]

Peter-

I can't speak for Sun, but I can tell you that the exception transparency
support in the BGGA prototype handles this kind of example with a single
exception type parameter.  There are situations where adding a type
parameter for each closure doesn't work (e.g. if the method accepts an
unbounded number of closures using varargs or a collection).

Cheers,
Neal

On Mon, Nov 30, 2009 at 1:52 PM, Peter Levart <peter.levart at gmail.com>wrote:

> Disjunctive types for exception transparency sound interesting.
>
> But how powerful can they be actually?
>
> Or to rephrase the question: How powerful are they allowed to be (by SUN)?
>
> For example:
>
> On Monday 30 November 2009 17:34:47 Neal Gafter wrote (in Re: Boxing
> function types):
> > <throws X> void invokeAll(#void()throws X left, #void()throws X right)
> > throws X { ... }
> >
>
> would it be possible to call the above method with this:
>
> invokeAll(
>  #() {
>    if (new Random().nextBoolean()) throw new IOException();
>    else throw InterruptedException();
>  },
>  #() {
>    if (new Random().nextBoolean()) throw new ParseException();
>    else throw InterruptedException();
>  }
> );
>
> ...and expect the compiler to infer X to be IOException | ParseException |
> InterruptedException
> ?
>
> Maybe this is not the right way to express the intention. Would then at
> least be possible to
> change the signature of the above method to:
>
> <throws X, throws Y> void invokeAll(#void()throws X left, #void()throws Y
> right) throws X|Y;
>
> ...to achieve the same effect?
>
> Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091130/a682f509/attachment.html