Closed timtebeek closed 1 year ago
Could even be interesting to catch and wrap the exception where the visit methods get called and then augment the wrapping exception with the line number of the object given to the visit method?
That could be a good way to do it indeed. As it stands such exceptions can be hard to debug.
Not sure what lines in jreleaser caused these issues, but the problem no longer occurs when I run it now. We could try to recreate the problem by checking out an old copy, and then use the new details about the visited element on exceptions if we really want to. But it I suggest we close this one for now, and wait for it to resurface if it ever does.
Wanted to run the common static analysis recipes against JReleaser after seeing he recently added SonarCloud scanning. Figured see if I can help out (with automation) as we met a few times over the summer; but after struggling a bit with the Gradle setup I ran up against a NPE in CatchClauseOnlyRethrows on line 67.
Steps to reproduce:
git clone git@github.com:jreleaser/jreleaser.git
cd jreleaser
sdk use java 11.0.17-tem
(Java 17 fails, so no helpful NPEs)cat > init.gradle
(instructions with some changes)./gradlew -d --init-script init.gradle rewriteRun -Drewrite.activeRecipes=org.openrewrite.java.cleanup.CommonStaticAnalysis
Expected: a successful run with maybe some changes.
Actual:
Aside from a fix for the NPE, it would be helpful to include in the output some reference to which file caused the issue in the first place. Especially when running on pre-helpful NPE versions of Java, that could help troubleshoot the problem and fix.