Simpler Java #1: No more NoPE's!!

The NullPointerException ("NPE"-> "NoPE" for its fans) is for sure one of the best friends of the JavaDeveloper. Why?

1. Null is in Java the Contract for "optional" Values, values which do not need to be there. Example: java.util.Map.get(key) returns null if the key was not found.
2. Some people tend to extend this even further and use null as the default return if the function call fails (rather than throwing an exception).
3. Variables in beans are not always initialized when the default constructor is used, which results in other NoPE pitfall.
4. Sometimes, null is also used to say "nothing". The difference between one and this one is crucial: Optional values are KNOWN to be not there, "nothing" instead is a pit waiting for a fall. It requires the dev to test for null every time explicitly. This comes to its worst when used with strings or or collections, which have a "natural" null value: The empty string / collection..

In all those situations, either the caller (1) might forget to check something or the api is just screwed (2-4) and gives you null to enforce You to nullcheck and clean its garbarge up - more than often, you won't, and your app says (once again): "NoPE"!

What can / should be done in these cases?

1. For optional values, null is per se ok (since its a java-developer contract accepted by most people). However, you MUST declare it clearly in the api! And try to do it seldomly.
2. Never return null just if an error occurs. Use _CHECKED_ exceptions! Or throw unchecked exceptions if the problem should have never been occured at all. Never return null just as a fallback: If you do not use the exception way, the program will crash with a _NoPE_ anyway, so returning null does not really improve your situation here..
3. Try to use "immutable" beans (more on that later), or at least try to make as much values as possible ready by the constructor. All other fields with "natural" empty values (strings, collections) should be given their "empty" default. Never null. Again.
4. Speaking of empty values: Strings and collections may never NEVER NEVER ever be null. There is the default empty value. USE IT! Do not try to make a difference between "nothing" and "empty". The only appropiate answer your program will give you is "NoPE".
5. MAKE EMPTY CONSTANTS FOR YOUR OWN OBJECTS. And another one. All immutable beans (that is, all "VALUES") should be given an empty default constant implementation which can be used as a default return value rather than null. Decide when you need it. But most of the time a constant holding the "EMPTY" instance of your class WILL be an asset. There are always situations which you cannot really handle but where you do not want to "NoPE" your app into cyberspace.. There the default comes very often to your help.

So much for some short thoughts and experience on handling null. Burn this into your memory:
If you get null and the api says so, because its an optional value, and you NoPE: SHAME ON YOU!
If you get null and no one has told you: SHAME ON THEM!
In the second case, ALWAYS the called code must be fixed. A caller should never nullcheck unless there is a really good DOCUMENTED reason.
Nullchecking in business apps is not "hardening" your code: Its just means that you have no clue whats going on in the code you've called... (If its YOUR code and not some framework, that is.)