Skip to content

SONARJAVA java:S1166 (either log or rethrow exception) should not raise an issue when using unnamed variables (conflict with rule java:S7467)#5383

Open
Jmanom wants to merge 1 commit intoSonarSource:masterfrom
Jmanom:S1166-unnamed-exceptions
Open

SONARJAVA java:S1166 (either log or rethrow exception) should not raise an issue when using unnamed variables (conflict with rule java:S7467)#5383
Jmanom wants to merge 1 commit intoSonarSource:masterfrom
Jmanom:S1166-unnamed-exceptions

Conversation

@Jmanom
Copy link

@Jmanom Jmanom commented Jan 2, 2026

Part of RSPEC

See description of problem in discussion
Request: Update rule java:S1166 (either log or rethrow) for cases using unnamed varliables

Please note:
The check if variable is unnamed is delibarately in

 @Override public void visitCatch(CatchTree tree) { if (!isExcludedType(tree.parameter().type()) && !excludedCatchTrees.contains(tree)) { Symbol exception = tree.parameter().symbol(); usageStatusStack.addFirst(new UsageStatus(exception.usages())); super.visitCatch(tree); if (usageStatusStack.pop().isInvalid() && !exception.isUnknown() **&& !isExceptionVariableUnnamed(tree.parameter())) {** context.reportIssue(this, tree.parameter(), "Either log or rethrow this exception."); } } } 

and not together with the excluded cases (like ParseException etc.) in the first line.

to allow for deeper evaluation like this (excerpt from the test cases):
Otherwise no issue (possibly not very likly but not an excluded case) would not be raised for the inner catch.

try { } catch (Exception _) { // Compliant try { } catch (Exception z) { // Noncompliant {{Either log or rethrow this exception.}} } } 
…se an issue when using unnamed variables (conflict with rule java:S7467)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

2 participants