Handling for new warning?

[Jonathan Gibbons]

Is this really a good idea -- adding the lint warning, with the 
downstream cost to projects that like to compile with `-Xlint:all -Werror`?

If nothing else, your note earlier that in JDK /there are thousands of 
methods with found to be missing "throws" for RuntimeExceptions that 
they currently don't declare./ is in itself a big red flag indicative of 
the impact of this change.

Before you post any proposed updates to javac or JDK, I suggest there 
should be a more general discussion on the desirability of this change, 
and its impact on existing code.

-- Jon


On 9/24/19 3:45 PM, Mike Duigou wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190924/cef1a059/attachment.html>