Re: Cleaning up IntelliJ warnings in code base

2022-05-27 Thread Mike Drob
Declaring an unused thrown exception in tests isn't the most critical change, but cleaning this up might help us discover accidental API signature changes in the future. If a test throws an exception then JUnit will figure it out and fail the test anyway, which is probably what we want to do

Re: Cleaning up IntelliJ warnings in code base

2022-05-27 Thread Eric Pugh
So, going through and cleaning up unused throwing of exceptions, I’ve touched all these files listed below. I was thinking I would do ONE commit for all of the “remove unused Exception”…. Before I keep going, wanted to make sure that makes sense….. modified:

Re: Cleaning up IntelliJ warnings in code base

2022-05-27 Thread David Smiley
IntelliJ is produced by a company and I have no idea how they go about selecting what the default inspections (what IntelliJ calls these) are. Maybe it was one person there, maybe it was arbitrary by whoever wrote the inspection, or maybe they had some more thoughtful approach that looked at

Re: Cleaning up IntelliJ warnings in code base

2022-05-27 Thread Shawn Heisey
On 5/27/2022 8:24 AM, Eric Pugh wrote: Hey all, was poking around at a unit test while watching TV and noticed lots of warnings from IntelliJ, little stuff like exceptions being thrown that don’t need to be thrown, unused variables, or typos. In eclipse, there are THOUSANDS of warnings.  And

Re: Cleaning up IntelliJ warnings in code base

2022-05-27 Thread Gus Heck
Yeah I'm certainly for cleaning up warnings, but I agree it should be in small chunks, and considered. In some cases "cleanup" will be //noinspection or @SuppressWarnings... Getting to a green check mark is quite beneficial, making it easier to notice when you've added something that's (possibly)

Re: Cleaning up IntelliJ warnings in code base

2022-05-27 Thread Michael Gibney
I have a vague recollection of having seen intellij warnings that really _shouldn't_ be "fixed". Unfortunately I'm not sure I'll be able to recall exactly what, but I thought I'd mention it as a word of caution, and in case it spurs anyone else's curiosity. Splitting any such PRs up by warning

Re: Cleaning up IntelliJ warnings in code base

2022-05-27 Thread Eric Pugh
Also, I guess I need to be careful to run spotless after I make changes to the tests per package. > On May 27, 2022, at 10:58 AM, Eric Pugh > wrote: > > Here is what I did the other night: > > https://github.com/apache/solr/compare/main...epugh:intellij_suggested_fixes >

Re: Cleaning up IntelliJ warnings in code base

2022-05-27 Thread Eric Pugh
Here is what I did the other night: https://github.com/apache/solr/compare/main...epugh:intellij_suggested_fixes I could just work on package by package, pushing them up, and if there is debate, I can just revert a commit on a package by package basis?? Thoughts? Eric > On May 27, 2022, at

Re: Cleaning up IntelliJ warnings in code base

2022-05-27 Thread Mike Drob
I would try to handle them in several small PRs either grouped by module or by warning type. On Fri, May 27, 2022 at 9:24 AM Eric Pugh wrote: > Hey all, was poking around at a unit test while watching TV and noticed > lots of warnings from IntelliJ, little stuff like exceptions being thrown >

Cleaning up IntelliJ warnings in code base

2022-05-27 Thread Eric Pugh
Hey all, was poking around at a unit test while watching TV and noticed lots of warnings from IntelliJ, little stuff like exceptions being thrown that don’t need to be thrown, unused variables, or typos. I was thinking about going through and fixing those, just to get the long list of