Handling for new warning?

Mike Duigou openjdk at duigou.org
Tue Sep 24 22:45:48 UTC 2019

This change applies only to the jdk.compiler module though there are 
probably many fixups which can be done later to fix the new warning. The 
Intellij refactoring seems like a reasonable way to get ahead of it.

I chose this change first because it doesn't require any JLS spec 
changes--it is just another lint "hygiene" warning.



On 2019-09-24 11:36, Brian Goetz wrote:
> And, even if you do it all at once, break it into two changesets --
> compiler and JDK -- since the review process is likely different
> between them.
> There is an IntelliJ refactoring "Add runtime exception to signatures"
> that can be used (recursively) to provide the correct signatures.
> On 9/24/2019 1:52 PM, Maurizio Cimadamore wrote:
>> As with all warnings - I think step 1 is to add the logic to javac 
>> (and disable them in the build), step 2 is to play whack a mole and 
>> fix occurrences in the JDK. Doing it all at once might just be too 
>> much.
>> Maurizio
>> On 24/09/2019 18:31, Mike Duigou wrote:
>>> I am working on a feature for javac that adds a new lint level 
>>> warning for undeclared thrown RuntimeExceptions. The patch itself is 
>>> small but since the compiler is built with all warnings enabled there 
>>> are thousands of methods with found to be missing "throws" for 
>>> RuntimeExceptions that they currently don't declare. Should I prepare 
>>> the patch of this new feature to include all of the warnings fixes or 
>>> omit them and explicitly disable the new warning in the build 
>>> configuration? The former would be more correct and complete but 
>>> masks the substance of the change in a huge volume of chaff. The 
>>> later would be more convenient and results in a more succinct path 
>>> but feels like a regression in not enabling all warnings.
>>> Cheers,
>>> Mike

More information about the compiler-dev mailing list