This past week I was looking over a number of merge requests and some of them had new methods declared with a return type of String (these are Java classes). With all of these methods if there is a logic issue or some unexpected behaviour then instead of returning an empty String object they all returned null. Personally this starts ringing alarm bells and waving red flags. Why is that you may ask?
If nulls are being returned, passed around to other methods, etc then the programmer will need to check before using that object (well they should anyway). There have been numerous times where I have seen programmers completely ignoring a null check for an object even though the method they used before to set that object could potentially return a null. With every one of these cases I politely leave a comment on the merge request, waiting until an update commit with the null checks are added before merging. Better safe than sorry.
Now am I being too cautious? I tend to lean towards the overly cautious side because it does not take much more lines of code and effort to ensure that the appropriate logging and checks are in place so that unexpected errors and problems with the software are not encountered by the user; plus it means that the software you are writing is safer. Let me know how you handle situations like this. Talking to some of the other programmers I know, they are split on the subject. Some don’t really care what is returned and don’t bother checking the object before use (those I call cowboy programmers), some don’t really care what is returned but do check before the object is used, and some care about what is returned and always check the object before use (I fall into this camp).
Potentially this problem is solved on a case by case basis. Is there a valid reason a null object should be returned? I’ll be doing some more reading about this to get a better understanding to ensure that I adhere to proper programming etiquette and safe programming.
Christopher Tom Kochovski 
You left out a group of programmers: those who care and intentionally do not check for null unless the possibility of returning null is described in the method’s header comment. The problem with reflexively checking every reference-type return value for null is that without a specified meaning for null, there is no “correct” way to handle it.
LikeLiked by 1 person
That is an absolutely fair point you raise. I think having meaningful documentation on the methods (Javadocs in my case) help tremendously and also having appropriate @Nonnull and @Nullable annotations to manage expectations will result in less NPEs too as the developer will not be as surprised. Every team has their own “correct” way to handle null and should be followed; again as you have stated there is no correct way to handle null.
LikeLike