Handling for new warning?

Mike Duigou openjdk at duigou.org
Wed Sep 25 00:46:37 UTC 2019





On 2019-09-24 16:25, mark.reinhold at oracle.com wrote:
> 2019/9/24 15:56:37 -0700, openjdk at duigou.org:
>> The proposed change is to add a lint level warning, ie.
>> -XLint:runtime-undeclared , suggestion to add the unrequired but 
>> missing
>> throws declarations for RuntimeException et al. The advantage to
>> providing the complete throws including RuntimeExceptions is to make
>> them more visible and encourage handling of them. We have one good
>> example of a library which does declare the RuntimeException that are
>> thrown, the JDK.
> 
> I’m confused.  I thought you said earlier that there are thousands of
> missing cases in the JDK.

JDK seems to be in pretty good shape though -Werror stops compilation 
well before completion. The observed problems with large numbers of 
missing declarations have been in javac where there are hundreds 
(perhaps many more) missing throws declarations primarily, so far, for 
IllegalArgumentException and CompletionFailure.

There's no easy way to know the total number of potential throws "fixes" 
needed because adding missing declarations has a tendency to produce new 
warnings in the methods which call the fixed method. I added a couple 
hundred across a dozen or so files but didn't feel I was any near 
complete based on the number of files I hadn't yet covered in the javac 
source.

> 
>> ...
>> 
>> The check will apply to all instances of RuntimeException and all
>> subclasses.
> 
> I agree with Jon: This proposal is likely to have broad impact and thus
> needs wider discussion.  May I suggest the jdk-dev list?


For JDK this would seem to be a separate problem--the missing "throws" 
could in some cases mean that the method signature and javadoc are an 
incomplete specification of the API and a potential/probable JCK issue.

For the moment I am going to working on completing the minimal patch 
which provides the new lint warning and allows compilation by disabling 
the warning.

> 
> - Mark


Cheers,

Mike


More information about the compiler-dev mailing list