Advice for bugfixing object oriented code: why is data not set?

Question

When debugging object oriented (Java) code, sometimes some field of some object is null while it should not be. I often spend what I feel is way too much time trying to figure out where it should have been set (at which point it's often quickly clear what went wrong).

If it had been a function argument, I'd be easy to trace where it came from by setting a breakpoint and following the stacktrace.

But if I have some ThingFunctions class which gets a ThingList from OtherThing and the Thing inside the list is missing it's id, I usually end up checking all usages of Thing.id, ThingList.add, OtherThing.setThingList and more just to find out who was responsible for setting the id.

Breakpoint don't help much since they only tell me where something happens, not where something doesn't happen.

This takes orders of magnitude more time than following a stacktrace to find why an argument is null. Is there an equally easy solution for debugging this problem? Any general advice? I have a modern IDE, other tools are welcome too.

Answer 1

There are two ways to deal with object state:

1. Have extremely sophisticated debugging skills so that you can find obscure bugs, or
2. Manage your state in a better way so that obscure bugs do not happen in the first place.

Ways to better manage object state:

1. Use constructors to build objects whose state is already valid.
2. Make your state private.
3. Write setter methods that validate changes in state. Block those state changes that are invalid.
4. Use immutable objects when appropriate.

Answer 2

One potential solution is to make sure that your object's field is always set in the constructor. Often, that will mean that the constructor takes the value of this field as an argument; it's much harder to forget to pass an argument to a constructor than it is to forget to set a field after the fact.

A potential downside is that you can't create the object until you know what the value of this field should be. Sometimes (usually?), the solution to this is pretty straightforward: just don't create the object until you know what the value of the field should be.

Answer 3

The most general advice is: make the atribute private.

Your object should be responsible of it state and not depend of others to be in a valid state. The API of the class should offer behavior not data manipulation.

Answer 4

This is a rather broad question, and the general answer is "use good architecture and design". Debugging will not help you, but designing your code correctly will.

• Design your application according to SOLID principles.
• Use immutable data structures.
• Enforce pre- and postconditions (i.e. fail fast); always construct your object into a valid state or crash otherwise.
• Don't allow null references across your public interfaces (within a class is ok if you can't avoid them in your programming language).
• Use value types instead of primitives (see primitive obsession).
• Use techniques from domain driven design.

You are absolutely right that nulls are problematic and that's why its inventor called it his "billion dollar mistake".

My bullet points are rather generic, but you can google and read up on each topic. You will then understand how you can become better at avoiding the problem.

Congratulations! Many programmers don't even realize that this is a problem and continue to write costly buggy code.