I inherited a project that I am managing and having to maintain pending the rede
ID: 651023 • Letter: I
Question
I inherited a project that I am managing and having to maintain pending the redevelopment of the code base. At the moment I am being tasked with adding little features all over the place and have gotten into the habit of returning null instead of zero in parts of the code where I am working on.
The problem is we have a client that is using this code and parts of code that require data from my implemented features receive a null and dump the stack trace in the UI.
I would like to avoid this entirely from my input but without the NullPointerException there's the potential that errors would be introduced into the client's data which may go un-noticed.
Usually I would have come up with my own error notification system but I have never inherited a project before. So I am unsure whether to continue down this path. I still believe that the stack dump is preferable to un-noticed data corruption/inaccuracies.
Explanation / Answer
I am currently reading Robert C. Martin's Clean Code and I finished the chapter on exception handling a few days ago. What he says is :
Returning null from methods is bad, but passing null into methods is worse
He goes on listing concrete examples on how you can avoid that, mainly:
when returning lists or arrays, return empty list or arrays
when returning non-collection objects, prefer returning "special case" objects, OR throwing exceptions. By "special case", I suppose it is for example returning an empty string (StringUtils.EMPTY if you work with the Apache Commons package), or a "NullObject" (thanks Thorbj