> On Oct 29, 2025, at 1:30 AM, Remi Forax <[email protected]> wrote: > > This is an interesting case because i'm not sure the compiler should emit an > error here. > > Currently the error occurs because as you said the call to super() is added > after the call to throw. > > But throwing an exception in a constructor of an identity class is valid, and > i do not see a reason why this behavior should not be the same in the case of > a value class.
It seems appropriate to call it an error, although the error message is confusing. This is a standard reachability check, nothing fundamentally new. But we have two spec problems: 1) JLS doesn't say that explicit constructor invocations must be reachable, although they really ought to be—they're not formally "statements", but they should be subject to the same rules. I filed a bug: https://bugs.openjdk.org/browse/JDK-8370899 2) JEP 401 introduces the possibility of unreachable *implicit* constructor invocations, and these need to be accounted for as well. I think it probably makes sense to treat these just like explicit constructor invocations, but I guess there could be an argument that reachability shouldn't apply to implicit things... (I noticed that the implicit code at the end of a compact record constructor is not checked, in the spec or javac, for reachability.) --- We do have practical use cases for constructors that always throw, so we should be careful not to break those cases. But I'm not sure it would make any sense to use the 'value' keyword with a class whose constructor always throws.
