The goal of defensive programming is to check that everything you want is in the right state before starting not the "I don't wanna exception way" of doing things.

In your case : some field can be empty by defintion. So no checking for null is just to avoid NRE is not defensive programming.

On my side defensive programming is mainly based on throwing (in java) IllegalStateException/IllegalArgumentException a lot.

Furthermore the first sample code you provide to illustrate what you want to ask is definitively wrong whatever way you want to go : cathing a NullReferenceException is a no go. By doing that, you may catch the NRE you want but if the code evolve, you may also catch unwanted NRE specially if later, you or someone else update the code.

Finally as an aside for the code you quoted the best move is just to switch the side of your test : selectedUser.equals(...) because you are probably sure at this point that selectedUser is neither null nor empty. This is not a defensive programming solution, just what you should do to have the clearest code and avoid unwanted errors.

The goal of defensive programming is to check that everything you want is in the right state before starting not the "I don't wanna exception way" of doing things.

In your case : some field can be empty by defintion. So no checking for null is just to avoid NRE is not defensive programming it is the normal way of handling it.

On my side defensive programming is mainly based on throwing (in java) IllegalStateException/IllegalArgumentException a lot (so I'm more in offensive programming as defined per Wikipedia).

Furthermore the first sample code you provide to illustrate what you want to ask is definitively wrong whatever way you want to go : cathing a NullReferenceException is a no go. By doing that, you may catch the NRE you want but if the code evolve, you may also catch unwanted NRE specially if later, you or someone else update the code.

Finally as an aside for the code you quoted the best move is just to switch the side of your test : selectedUser.equals(...) because you are probably sure at this point that selectedUser is neither null nor empty. This is not a defensive programming solution, just what you should do to have the clearest code and avoid unwanted errors.

I am the kind of programmer that use defensive programming a lot. However if I would have to handle some communication with a 3rd party that give me possibly null value and such stuff, I would rather fill it with default empty strings, etc.

However in your specific case it is not necessary : just switch the side of your test : selectedUser.equals(...) because you are probably sure at this point that selectedUser is neither null nor empty.

The goal of defensive programming is to check that everything you want is in the right state before starting not the "I don't wanna exception way" of doing things.

In your case : some field can be empty by defintion. So no checking for null is just to avoid NRE is not defensive programming.

On my side defensive programming is mainly based on throwing (in java) IllegalStateException/IllegalArgumentException a lot.

Furthermore the first sample code you provide to illustrate what you want to ask is definitively wrong whatever way you want to go : cathing a NullReferenceException is a no go. By doing that, you may catch the NRE you want but if the code evolve, you may also catch unwanted NRE specially if later, you or someone else update the code.

Finally as an aside for the code you quoted the best move is just to switch the side of your test : selectedUser.equals(...) because you are probably sure at this point that selectedUser is neither null nor empty. This is not a defensive programming solution, just what you should do to have the clearest code and avoid unwanted errors.