UnreachableCatchBlock gives false positive for unresolved classes

[thejk]

Expected Behavior

No UnreachableCatchBlock warnings should be triggered for classes that could for some reason not be resolved.

Observed Behavior

UnreachableCatchBlock treats each unresolved class as a subclass of each other triggering warnings.

Steps to Reproduce

fun test() {
    try {
    } catch (e: Foo) {
    } catch (e: Bar) {
    }
}

Running detekt with type resolution enabled but Foo and Bar missing from classpath.
detekt-cli -cp . -i test.kt
Output (I've removed other warnings for clarity):

test.kt:10:7: This catch block is unreachable. [UnreachableCatchBlock]

Context

Getting the classpath for type resolution correct for detekt is not easy and getting unrelated warnings because a type doesn't resolve isn't helping.

Your Environment

• Version of detekt used: 1.23.3
• Operating System and version: Lnux 6.1.61 x86_64

[josephlbarnett]

same as/related to #6129 ?

[thejk]

Might be the same base issue (ClassDescriptor for unresolved classes not useful) but no overlap with Kotlin's unreachable code detection in UnreachableCatchBlock I think.

[3flex]

Getting the classpath for type resolution correct for detekt is not easy

This is the actual issue that we'd want to fix. Is there a specific problem you're facing in passing the right classpath? That might inspire PRs to improve the situation.

[thejk]

I'm still looking at why the types are not resolved in the real project, but with more than 100 dependencies and their transitive dependencies it's hard to nail down.

That said, should detekt show errors for unresolved types then? Because the only output right now is an incorrect warning about UnreachableCatchBlock which I think is unhelpful (I had to read the rule source code to figure out why it was warning about two unrelated exception classes).

[thejk]

Found the reason for the missing classes, an Android project and the bootclasspath was not included (so java.lang.Object was missing).

So, for me, a more visible warning about missing classes would make false positives caused by the missing classes less confusing. Not showing the false positives for missing classes would also help.

[BraisGabin]

So, for me, a more visible warning about missing classes would make false positives caused by the missing classes less confusing. Not showing the false positives for missing classes would also help.

This is a kind of controversial topic and we had different ideas reggarding this. At the begginig we were REALLY verbose. Fro that reason we added #4423. But even that was too noisy for some people so we end up with #5449.

The problem is that there is too difficult to configure the classpath correctly and on Android it is kind of impossoble so those messages doesn't help too much.

If you run detekt on debug mode you will see all the issues.

[thejk]

I see, I would have suggested something like number reporting in #4423, but fair enough, until it's possible to always get it to zero it's not good. Just have to get used to set debug = true as soon as I get any weird reports.

I'm resolving this as I believe there are enough issues about this, thanks for the info.