search

nikialeksey / nullfree

Nullfree will fail your build if your project has a null.
https://www.iwillfailyou.com/nullfree
MIT License
14 stars 1 forks source link

Dynamic NPE cases #9

Open razum2um opened 5 years ago

razum2um commented 5 years ago

Based on approach taken in https://github.com/nikialeksey/nullfree/blob/d9b270a6ed31d2cd0556139e80d5531bcb023923/lib/src/main/java/com/nikialeksey/nullfree/sources/java/JavaSourceFile.java#L63

I think the famous NPE is happening 10% because of explicit return null; / x = null; in various flavours, but 90% due something like HashMap.get("non-existing-key") or getters for non-initialised object fields with defaults, e.g. name in https://www.codebyamir.com/blog/stop-returning-null-in-java

Besides, in the second case, it makes sense to skip/allow != null pattern as comparison doesn't do any harm + it's often unavoidable for an imported library classes you don't control

nikialeksey commented 5 years ago

Agreed with you about comparision with null (https://github.com/nikialeksey/nullfree/issues/10).

Absolutely, there is cases with NPE due to non-initialised fields, or non existing keys in map, but I did see this statistics, and it's pretty hard to implement dynamic npe analysis. I think, we can avoid many cases of dynamic NPE by other ways: use only final fields, every check map for existing or not keys and so on. Good idea for new static analysis.