Handling for new warning?

[Mike Duigou]

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.

Cheers,

Mike

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