NullPointerException<\/code> on some code path<\/li>\n- Condition is always true or false in all possible code paths<\/li>\n
- Array index is always out of bounds in all possible code paths<\/li>\n
- Type cast will always fail<\/li>\n<\/ul>\n
These facts do not always signal a bug. For example, one may want to add an always-true statement for code clarity, like in this case:<\/p>\n
if (obj == null) {\r\n \u2026\r\n} \r\nelse if (obj != null) { \/\/ 'obj != null' is always true reported here\r\n \u2026\r\n}<\/pre>\n
\nHowever often such warnings signal that code contains a typo or the code author did not examine the code behavior fully. This inspection may help to discover really weird bugs which are not covered by any patterns. Sometimes even we, the IDE authors, could not imagine the code snippet in which \u201cConstant conditions & exceptions\u201d warning was issued.<\/p>\n
Over the years we have been constantly improving this inspection. It used to be mostly concentrated on nullability and type analysis. Later we added Optional presence analysis, integral ranges analysis, and array bounds checking. In the previous major release 2017.3, we improved integral ranges analysis and added basic support for Stream API and Optional call chains.<\/p>\n
The first big testing of \u201cConstant conditions & exceptions\u201d is performed on the source code of IDEA Ultimate itself. It\u2019s quite a huge project as the codebase contains tens of thousands of classes, written by dozens of developers, over more than 15 years. After the next inspection improvement, it\u2019s always interesting to discover yet another bug in some ancient class. Let’s see what we have found after improving the dataflow analysis for the upcoming release.<\/p>\n
One of the most interesting dataflow analysis improvements in 2018.1 is the tracking of relations between variables. In older IDEA versions the inspection tracked the variables equality or inequality, so if(a == b && a != b)<\/code> was highlighted as always false. When we started tracking integral ranges, new warnings appeared in the code like if(a > 0 && a <= 0)<\/code>, because the first condition implies that the a<\/code> value belongs to the range [1..MAX_VALUE]<\/code> while the second condition requires the range [MIN_VALUE..0]<\/code> and these ranges never intersect. However, up until now, there was no warning on an if(a > b && a <= b)<\/code> condition because we knew nothing more about the value of these two variables. Now we have started to track which variable is greater, so in 2018.1 this snippet will be highlighted as well. This might look pretty trivial and such mistakes would unlikely remain unnoticed in the code, but remember that dataflow analysis doesn\u2019t just track specific code patterns.<\/p>\nFirst, it can easily detect an opposite case, and it was actually found in some SQL tables processing code:<\/p>\n
![\"idx](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2018\/01\/idea-1_getancestorrefs.png\")
<\/a><\/p>\nYes, the method starts with an always true condition, so it always returns the empty list, because the idx<\/code> variable is always either less than the myAncestorRefs<\/code> array length, or greater, or equal to. The following ten lines of code were never executed. It\u2019s obviously a typo: idx < 0<\/code> was intended instead of idx < myAncestorRefs.length<\/code>.<\/p>\nSpeaking of array lengths, it appeared that the new feature nicely couples with already existing arrays bounds checking. The following code snippet was discovered in our Groovy plugin:<\/p>\n
![\"if](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2018\/01\/idea-2_getinitializerfor.png\")
<\/a><\/p>\nNow at the array access expression, the inspection knows that the i<\/code> value is always greater than the initializers<\/code> array length. Thus an ArrayIndexOutOfBoundsException<\/code> is inevitable if this code is executed. Clearly the condition was mistakenly flipped.<\/p>\nAnother array-related problem was discovered in the source code of some Java inspection which processes catch blocks:<\/p>\n
![\"while](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2018\/01\/idea-3_issuperclassexceptioncaughtlater.png\")
<\/a><\/p>\nAs you can see, the index<\/code> bound is checked after it\u2019s used to access an array element. Thus the condition can never be false: if it\u2019s false, then ArrayIndexOutOfBoundsException<\/code> would be thrown right before.<\/p>\nNow in some cases, we track values from array initializer expressions. This has allowed us to discover some redundant code like this:<\/p>\n
![\"boolean[]](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2018\/01\/idea-4_copyclassesimpl.png\")
<\/a><\/p>\nLong ago the result<\/code> one-element array was used inside the command<\/code> lambda to record that editor activation is necessary. Later during code evolution, the editor activation became unnecessary, but the redundant condition was not reported by any existing inspection. Now we clearly see this.<\/p>\nBoolean methods starting with \u201cis\u201d are now assumed to return the same result if called twice in a row on the same qualifier value. This is a heuristic, which is not necessarily true, but if it produces a false-positive warning, then it\u2019s probably a sign that the code would be confusing not only for the IDE, but for other teammates as well. Here\u2019s a bug which was discovered in CSS selectors handling code thanks to this improvement:<\/p>\n
![\"localSelectorElement.isUniversalSelector()](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2018\/01\/idea-5_getsourcerange.png\")
<\/a><\/p>\nEven though the qualifiers are different here, they were assigned to the same value previously. Thus we assume that isUniversalSelector<\/code> would return the same result. The typo is actually not in the condition, but in a line above: of course it should be remoteSelectorElement = (CssSimpleSelector)remoteSelectorElements[j]<\/code>.<\/p>\nSince 2018.1 we added another kind of warning. When a variable is assigned to a value, we warn you if it already contains the same value on every possible execution path. Again, it doesn\u2019t always indicate a bug, but it may help to remove redundant code. However real bugs also could be found with the help of this warning. For example, the following code was found in our HTML formatting tests:<\/p>\n
![\"int](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2018\/01\/idea-6_testindent.png\")
<\/a><\/p>\nThe problem is three lines above the warning: the first line of the code fragment should not have \u201c= 2<\/code>\u201d at the end. As a result, previous indent size is not restored in the finally block.<\/p>\nAlso, this warning sometimes allows you to spot duplicates in the field or array initialization series like here:<\/p>\n
![\"defaults[CONSTANT_Int]](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2018\/01\/idea-7_abc.png\")
<\/a><\/p>\nThis line is probably redundant, or something else was meant to be here instead, but it\u2019s clearly a mistake.<\/p>\n
Trivial improvement in this<\/code> reference handling revealed a bug in our tabs UI control:<\/p>\n![\"while](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2018\/01\/idea-8__findInfo.png\")
<\/a><\/p>\nAs known, the disjunction operator is short-circuited: if the first condition is true, then the second is not checked. If the first condition is false, then component<\/code> equals to this<\/code>, but this<\/code> is never null, which means the component<\/code> is not null as well. Thus the whole condition is always true. It\u2019s a very common mistake when ||<\/code> was used instead of &&<\/code> and vice versa.<\/p>\nFinally, we improved Stream API processing inside dataflow analysis. In particular, it now works for incomplete stream chains as well (that is, stream chains not ending with the terminal operation). No actual bugs were discovered because of this improvement, but several redundant code occurrences were found. For example, a method like this appears in our code coverage processing:<\/p>\n
![\"mapToObj(idx](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2018\/01\/idea-9_getmissingbranches.png\")
<\/a><\/p>\n