Challenge exception inference

[stephan-herrmann]

Challenge exception inference

[stephan-herrmann]

To recap the role of exception constraints during inference, here's as central statement from 18.2.1:

We do not attempt to produce bounds on inference variables that appear in the target function type's throws clause. This is because exception containment is not part of compatibility (§15.27.3) - in particular, it must not influence method applicability (§18.5.1). However, we do get bounds on these variables later, because invocation type inference (§18.5.2.2) produces exception containment constraint formulas (§18.2.5).

This helps to explain, why in the above example leaving getEx() under specified results in method ambiguity, even when we remove throw new IllegalAccessException(); from the lambda body. Knowing that only IOException can be thrown doesn't help selecting one of the overloads based on inferring X. This inference happens only after applicability inference.

For the same reason, availability of test() will only be determined after inference, because it needs the result of invocation type inference.

[stephan-herrmann]

This item from 18.2.5. is incompletely implemented in ecj:

If n = 0 (the function type's throws clause consists only of proper types), then if there exists some i (1 ≤ i ≤ m) such that Xi is not a subtype of any proper type in the throws clause, the constraint reduces to false; otherwise, the constraint reduces to true.

We don't have that 'false' case.

[stephan-herrmann]

In 18.2.5. E' (JLS 8) has been renamed to X (JLS 22) but other than that plus the omission mentioned above, our implementation of exception inference is well-aligned with the spec, still.