SONARJAVA-6305 Fix the expected exceptions filter to work without semantic information

[aurelien-coet-sonarsource]

---

Summary by Gitar

• Refactored filter to work without semantic information: Replaced MethodMatchers (requiring semantic data) with method name string matching; converted from type-based checks to simple name comparisons. Changes exception matching from type hierarchy checks to simple string set lookups for robustness.
• Generalized exception handling: Renamed methods and sets from DateTimeException-specific to generic exception handling; filter now supports any exception type via expectedExceptions parameter.
• Test coverage: Added test cases for method invocations and annotations without semantic information to verify conservative filter activation.

_{This will update automatically on new commits.}

[sonarqubecloud]

Agentic Analysis: Early Results

Agentic Analysis and Context Augmentation are available on your project. Here are some issues that could have been prevented. Follow the links to learn how to put them into action.

5 issue(s) found across 1 file(s):

Rule	File	Line	Message
java:S2201	java-checks/src/test/files/filters/ExpectedExceptionFilter.java	157	The return value of "from" must be used.
java:S2201	java-checks/src/test/files/filters/ExpectedExceptionFilter.java	166	The return value of "from" must be used.
java:S2201	java-checks/src/test/files/filters/ExpectedExceptionFilter.java	171	The return value of "from" must be used.
java:S2201	java-checks/src/test/files/filters/ExpectedExceptionFilter.java	187	The return value of "from" must be used.
java:S2201	java-checks/src/test/files/filters/ExpectedExceptionFilter.java	192	The return value of "from" must be used.

_{Analyzed by SonarQube Agentic Analysis in 5.5 s}

[hashicorp-vault-sonar-prod]

SONARJAVA-6305

[gitar-bot]

Code Review ✅ Approved 2 resolved / 2 findings

Fixes the expected exceptions filter to work without semantic information by adding guards to argument index accesses and reducing cognitive complexity. Duplicate test method names and unchecked index access issues have been resolved.

✅ 2 resolved

✅ Quality: Duplicate method name in test file

📄 java-checks/src/test/files/filters/ExpectedExceptionFilter.java:158 📄 java-checks/src/test/files/filters/ExpectedExceptionFilter.java:162
The test file defines two methods both named methodAnnotationWithoutSemantics (lines 158 and 162). While Java allows method overloading, these methods have the same signature (both take no arguments and return void), which will cause a compilation error.

✅ Edge Case: Unchecked argument index access may throw IndexOutOfBoundsException

📄 java-checks/src/main/java/org/sonar/java/filters/ExpectedExceptionFilter.java:128 📄 java-checks/src/main/java/org/sonar/java/filters/ExpectedExceptionFilter.java:137-138 📄 java-checks/src/main/java/org/sonar/java/filters/ExpectedExceptionFilter.java:130-135
The refactoring replaced MethodMatchers (which validated parameter count via addParametersMatcher) with name-based matching, but didn't add equivalent bounds checks on argument lists. If a method with the same name but a different signature is encountered (plausible since this is name-only matching), arguments.get(1) or arguments.get(0) will throw IndexOutOfBoundsException.

Three sites are affected:

• Line 128: catchThrowableOfType accesses arguments.get(1) without checking arguments.size() >= 2
• Line 137: assertThatExceptionOfType/thenExceptionOfType accesses arguments.get(0) without checking non-empty
• Line 138: isThrownBy accesses mit.arguments().get(0) without checking non-empty

Since the filter now intentionally matches by name alone, it's more likely to encounter unexpected method signatures.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
90.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube