I\'m new to android/java programming and am confused how to properly deal with this warning.
Method invocation \'\' may produce \'Java.lang.NullPointe
I've used Objects.requireNonNull()
which is a good way IMO. As @matiash mentioned, this is not a fool-proof way for every use case, but where you are sure that data won't be null
, you can use this approach to get rid of the warning. And if it does fail for some unknown reason, you will get NullPointerException
which you will get anyway without using this.
// before
cal.setTime(date);
// after
cal.setTime(Objects.requireNonNull(date));
Yes. Using if (Object != null){}
for validating is the proper way. try {} catch (NullPointerException) {}
is the next solution which is preferred in this case.
If you want to get ride of it, throw an NullPointerException
. Lint will ignore it in this case. public void myFunc() throws NullPointerException{}
.
Anyway, good Coding always means validating everything for a possible problem while runtime. Validating != null
is just fine and should always be used whenever it's possible null.
I like the answer to this link.
Warning is not an Error. And the warning which you are talking about says "it may produce", don't say 'it must produce'. So choice is yours. Either add null check or not
So, If you are sure that findViewById in your code will never be cause of NPE, then don't add the null check.
I doubt this question can be answered conclusively, as it's a matter of opinion. Or at least I believe so -- an opinion too. :)
I understand you want "0 warnings" (a very laudable goal) but there's probably not a "one size fits all" issue. That said...
Things I believe you should not do:
NullPointerException
. This would be a bad idea, generally. In this case, since you're probably overriding onOptionsItemSelected()
, it's not even possible.Checking for (variable != null)
is generally the best approach. What to do if it is, though, presents some other options.
searchView
isn't there, just do so. For example, just return from the method. It's a good idea to log this situation though, so you can spot it while testing.RuntimeException
, these exceptions are unchecked, and hence will probably cause the app to crash.What @Herrbert74 suggested it surely working fine, but sometimes it's better to not add a @SuppressWarnings("ConstantConditions")
to an entire method (if it's not trivial), a better approach could be to use //noinspection ConstantConditions
on the warned line.
Those are my rules of thumb:
Use
@SuppressWarnings("ConstantConditions")
when the method is simpleUse
//noinspection ConstantConditions
when the method is complex and you need to remove the warning only on a specific line
As @matiash pointed out there is no one-size-fits-all solution.
For me a good compromise was to disable NullPointerException
warning for all calls to findViewById()
and keep it for other method calls. That way I take responsibility for checking the resource ids but still get a benefit of getting warnings if I make other mistakes.
To achieve this I added _ -> !null
method contract with Android Studio quick fix menu.
The action generated a following file file at android/support/v7/app/annotations.xml
in my project root.
<root>
<item name='android.support.v7.app.AppCompatActivity android.view.View findViewById(int)'>
<annotation name='org.jetbrains.annotations.Contract'>
<val val=""_ -> !null"" />
</annotation>
</item>
</root>
Update: Unfortunately it doesn't survive Android Studio restarts :-( External annotations are really useful so I hope I'll figure out a way to make Android Studio load them after restart.