Wrongly highlights “Condition string != null” is always true

private String getString() throws Exception {
return null;
}

private String test() throws Exception {
String string = null;
try {
string = getString();
return string.substring(0);
} catch (Exception e) {
throw e;
} finally {
if (string != null) getString();
^
|_______________
}
}

4 comments
Comment actions Permalink

Vote for

http://www.intellij.net/tracker/idea/viewSCR?publicId=17835

filed against build 944(!) and, as you've discovered, still broken.

I ask about the status of this bug from time to time and never get an
answer from JetBrains.

Vladimir Goncharov wrote:

private String getString() throws Exception {
return null;
}

private String test() throws Exception {
String string = null;
try {
string = getString();
return string.substring(0);
} catch (Exception e) {
throw e;
} finally {
if (string != null) getString();
^
|_______________
}
}

0
Comment actions Permalink

in contrast to http://www.intellij.net/tracker/idea/viewSCR?publicId=17835 I think the "always-true"-highlighting in Vladimir's case is NOT wrong:

private String getString() throws Exception {
return null;
}

private String test() throws Exception {
String string = null;
try {
string = getString(); // always null, equal to = null, since ex is never thrown by getString()
return string.substring(0);// always throws ex, but not important
} catch (Exception e) {
throw e; // whatever
} finally {
if (string != null) getString(); // string is null as it always was, btw what should the call of getString() do without assignment?

thoughts? - greets

0
Comment actions Permalink


private String getString() throws Exception {
throw new RuntimeException();
}


Now string is null.

0
Comment actions Permalink

The old URL is broken. In case anyone else goes looking, I'm pretty sure this is the same bug, because it mentions "build 944" and includes the title mentioned here:

    https://youtrack.jetbrains.com/issue/IDEA-27370

(On the other hand, it says it was fixed back in 2011, with very little in the way of visible change history.)

The code above and in the bug report seem to be handled correctly now. I have another, more complex case which seems to be handled wrongly, but I haven't been able to reduce it to something manageable.

0

Please sign in to leave a comment.