Return to Answer

You should not catch a NullPointerException - in fact very few RuntimeExceptions should be caught.

A NullPointerException denotes a problem with your code, where a variable is invoked methods upon (or its fields are accessed), while the reference actually has a null value.

This essentially mandates checking for null values.

That's where Android Studio seems to be pedantically proactive in this context: of course you may get NPEs by chaining method invocations on objects, and if you do not have a guarantee that the objects will not be null, you should check for null values.

For instance:

if (resultCode == 100 && data.getExtras().get("x") != null && data.getExtras().get("y") != null && data.getExtras().get("address") != null) { ... 

... would become, tediously:

if (resultCode == 100 && data != null // unlikely && data.getExtras() != null && data.getExtras().get("x") != null ... 

... or rather, in this instance:

if (resultCode == 100 && data != null // unlikely && data.hasExtra("x") ... 

That change is tedious and adds clutter, but it will hardly matter in terms of performance, as long as your method invocations are not mutating any object (otherwise, just assign to a variable before checking for null values).

There seem to be ways to parametrize Android Studio with regards to the warnings you get from the IDE.

See this question for the general direction.

Note/Late edit

As this is an old answer, a word about Java 8's Optional.

• Optionals are meant to convey the concept of data that may or may not be there, such as an instance of the referenced object.
• In other words, an Optional<T> is a container for an instance of T whose presence we are not sure about.
• The Optional class features a number of methods to deal with this uncertainty a lot more elegantly than having to tediously perform null checks, or some may argue, than having to deal with the concept of pointers at all in the first place, as conveyed by dreaded NullPointerExceptions.
• Optionals are massively employed in Java 8´s stream API.
• Finally, here's a good starting point on Optionals from Oracle's own point of view.

You should not catch a NullPointerException - in fact very few RuntimeExceptions should be caught.

A NullPointerException denotes a problem with your code, where a variable is invoked methods upon (or its fields are accessed), while the reference actually has a null value.

This essentially mandates checking for null values.

That's where Android Studio seems to be pedantically proactive in this context: of course you may get NPEs by chaining method invocations on objects, and if you do not have a guarantee that the objects will not be null, you should check for null values.

For instance:

if (resultCode == 100 && data.getExtras().get("x") != null && data.getExtras().get("y") != null && data.getExtras().get("address") != null) { ... 

... would become, tediously:

if (resultCode == 100 && data != null // unlikely && data.getExtras() != null && data.getExtras().get("x") != null ... 

... or rather, in this instance:

if (resultCode == 100 && data != null // unlikely && data.hasExtra("x") ... 

That change is tedious and adds clutter, but it will hardly matter in terms of performance, as long as your method invocations are not mutating any object (otherwise, just assign to a variable before checking for null values).

There seem to be ways to parametrize Android Studio with regards to the warnings you get from the IDE.

See this question for the general direction.

Note/Late edit

As this is an old answer, a word about Java 8's Optional.

• Optionals are meant to convey the concept of data that may or may not be there, such as an instance of the referenced object.
• In other words, an Optional<T> is a container for an instance of T whose presence we are not sure about.
• The Optional class features a number of methods to deal with this uncertainty a lot more elegantly than having to tediously perform null checks, or some may argue, than having to deal with the concept of pointers at all in the first place, as conveyed by dreaded NullPointerExceptions.
• Optionals are massively employed in Java 8´s stream API.
• Finally, here's a good starting point on Optionals from Oracle's own point of view.

You should not catch a NullPointerException - in fact very few RuntimeExceptions should be caught.

A NullPointerException denotes a problem with your code, where a variable is invoked methods upon (or its fields are accessed), while the reference actually has a null value.

This essentially mandates checking for null values.

That's where Android Studio seems to be pedantically proactive in this context: of course you may get NPEs by chaining method invocations on objects, and if you do not have a guarantee that the objects will not be null, you should check for null values.

For instance:

if (resultCode == 100 && data.getExtras().get("x") != null && data.getExtras().get("y") != null && data.getExtras().get("address") != null) { ... 

... would become, tediously:

if (resultCode == 100 && data != null // unlikely && data.getExtras() != null && data.getExtras().get("x") != null ... 

... or rather, in this instance:

if (resultCode == 100 && data != null // unlikely && data.hasExtra("x") ... 

That change is tedious and adds clutter, but it will hardly matter in terms of performance, as long as your method invocations are not mutating any object (otherwise, just assign to a variable before checking for null values).

There seem to be ways to parametrize Android Studio with regards to the warnings you get from the IDE.

See this question for the general direction.

You should not catch a NullPointerException - in fact very few RuntimeExceptions should be caught.

A NullPointerException denotes a problem with your code, where a variable is invoked methods upon (or its fields are accessed), while the reference actually has a null value.

This essentially mandates checking for null values.

That's where Android Studio seems to be pedantically proactive in this context: of course you may get NPEs by chaining method invocations on objects, and if you do not have a guarantee that the objects will not be null, you should check for null values.

For instance:

if (resultCode == 100 && data.getExtras().get("x") != null && data.getExtras().get("y") != null && data.getExtras().get("address") != null) { ... 

... would become, tediously:

if (resultCode == 100 && data != null // unlikely && data.getExtras() != null && data.getExtras().get("x") != null ... 

... or rather, in this instance:

if (resultCode == 100 && data != null // unlikely && data.hasExtra("x") ... 

That change is tedious and adds clutter, but it will hardly matter in terms of performance, as long as your method invocations are not mutating any object (otherwise, just assign to a variable before checking for null values).

There seem to be ways to parametrize Android Studio with regards to the warnings you get from the IDE.

See this question for the general direction.

Note/Late edit

As this is an old answer, a word about Java 8's Optional.

• Optionals are meant to convey the concept of data that may or may not be there, such as an instance of the referenced object.
• In other words, an Optional<T> is a container for an instance of T whose presence we are not sure about.
• The Optional class features a number of methods to deal with this uncertainty a lot more elegantly than having to tediously perform null checks, or some may argue, than having to deal with the concept of pointers at all in the first place, as conveyed by dreaded NullPointerExceptions.
• Optionals are massively employed in Java 8´s stream API.
• Finally, here's a good starting point on Optionals from Oracle's own point of view.

You should not catch a NullPointerException - in fact very few RuntimeExceptions should be caught.

A NullPointerException denotes a problem with your code, where a variable is invoked methods upon (or its fields are accessed), while the reference actually has a null value.

This essentially mandates checking for null values.

That's where Android Studio seems to be pedantically proactive in this context: of course you may get NPEs by chaining method invocations on objects, and if you do not have a guarantee that the objects will not be null, you should check for null values.

For instance:

if (resultCode == 100 && data.getExtras().get("x") != null && data.getExtras().get("y") != null && data.getExtras().get("address") != null) { ... 

... would become, tediously:

if (resultCode == 100 && data != null // unlikely && data.getExtras() != null && data.getExtras().get("x") != null ... 

... or in this instance:

if (resultCode == 100 && data != null // unlikely && data.hasExtra("x") ... 

That change is tedious and adds clutter, but it will hardly matter in terms of performance, as long as your method invocations are not mutating any object (otherwise, just assign to a variable before checking for null values).

There seem to be ways to parametrize Android Studio with regards to the warnings you get from the IDE.

See this question for the general direction.

You should not catch a NullPointerException - in fact very few RuntimeExceptions should be caught.

A NullPointerException denotes a problem with your code, where a variable is invoked methods upon (or its fields are accessed), while the reference actually has a null value.

This essentially mandates checking for null values.

That's where Android Studio seems to be pedantically proactive in this context: of course you may get NPEs by chaining method invocations on objects, and if you do not have a guarantee that the objects will not be null, you should check for null values.

For instance:

if (resultCode == 100 && data.getExtras().get("x") != null && data.getExtras().get("y") != null && data.getExtras().get("address") != null) { ... 

... would become, tediously:

if (resultCode == 100 && data != null // unlikely && data.getExtras() != null && data.getExtras().get("x") != null ... 

... or rather, in this instance:

if (resultCode == 100 && data != null // unlikely && data.hasExtra("x") ... 

That change is tedious and adds clutter, but it will hardly matter in terms of performance, as long as your method invocations are not mutating any object (otherwise, just assign to a variable before checking for null values).

There seem to be ways to parametrize Android Studio with regards to the warnings you get from the IDE.

See this question for the general direction.