Community
Participate
Working Groups
Build ID: I20070621-1340 Steps To Reproduce: assert transformer != null : "null transformer for " + key; if (transformer == null) return null; I get a redundant null check error on the second statement, which is a false positive since asserts have to be enabled to take effect, hence the variable can be null at that location.
We deliberately decided that assertions and null reference analysis should work hand in hand (see bug 127244), the null reference analysis always pretending that assertions would be executed. The rationale behind this is that some developers use assertions to program by contract, and that when they take care of a potential null condition by protecting it by an assert, then they should be confident that the protection is recognized downstream by the null analysis, which should no more have doubts about the null valuation of the protected variables. We believe that this brings more value to the developer than the more conservative approach that would consider that, the execution of assertions being conditioned at runtime, their influence upon variables null status should be disregarded. Resolving as WONTFIX.
I see the rationale for doing that. Might it be an idea to make this a configurable preference?
If you believe this is forth it, please feel free to open a feature request. Would need to think more about the details (name, precise semantics, impact on other related cases and relative priority to other tentative null-related options) before making progress though, especially because we try hard to keep the number of options in that area reasonably low.
Verified for 3.4M1
*** Bug 234549 has been marked as a duplicate of this bug. ***
This got fixed along with the fix for bug 325342. *** This bug has been marked as a duplicate of bug 325342 ***
