JDK-8062234 : 8.8.9: Allow call to super constructor that 'throws RuntimeException'
  • Type: Bug
  • Component: specification
  • Sub-Component: language
  • Affected Version: 7,8
  • Priority: P5
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2014-10-27
  • Updated: 2016-07-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbd_majorUnresolved
Related Reports
Relates :  
Description
The body of a default constructor is a 'super()' call; the following rule ensures that this call is valid:

"It is a compile-time error if a default constructor is implicitly declared but the superclass does not have an accessible constructor that takes no arguments and has no throws clause."

However, the rule is stricter than necessary, and is stricter than longstanding javac behavior (I tested 6, 7, and 8).

A better test: does the invocation type (15.12.2.6) of the implicit super constructor invocation (8.8.7.1) throw any types that are not subtypes of RuntimeException?  (Note that the connection between 8.8.7.1 and 15.12.2 is not spelled out -- see JDK-8034925.)
Comments
To be more explicit about why this change is okay: 8.8.9 is attempting to enforce the general rule that all checked exceptions that an expression can throw are either caught or declared to be thrown. In the case of the default constructor body, that means that the implicit 'super()' call must throw no checked exceptions. But the existing rule takes this a step further, asserting that the 'super()' call can throw no exceptions at all; in fact there's nothing wrong with a 'super()' call that can throw unchecked exceptions.
28-10-2014

I considered allowing a rule like this, that sort of "inlines" the 15.12.2 logic, as applied to 'super()': Every type mentioned by the throws clause (if any) is either i) a subtype of RuntimeException, or ii) a type variable with upper bound Exception or Throwable and no other upper bound. But there are holes: what if the 'throws' type variable is a type parameter of the _class_, not of the _constructor_? Then the legality of the call depends upon the substitution applied to that type parameter. We can try patching it up, but ultimately I think we're bound to get this wrong, and it makes a lot more sense to simply defer to the 15.12.2 logic (as javac does).
27-10-2014