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.

  • 3
    There's no silver bullet for your problem, it is quite common in Object Oriented programming, and making it better requires some pretty big re-writing.
    – GHP
    Sep 14, 2017 at 17:05
  • General advice: use getters and setters instead of directly accessing fields... that way you can use your IDE tools to track down all locations where it is set rather than also where is it used. Sep 15, 2017 at 2:15

4 Answers 4


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.
  • 1
    "obscure bugs do not" -> "obscure bugs cannot"?
    – Caleth
    Sep 14, 2017 at 16:04
  • 1
    They can. Better state management only reduces the risk; it does not eliminate it. Sep 14, 2017 at 16:05
  • I would add, set or change each piece of state in as few places as possible. And keep your call chain from higher to lower level objects, avoiding calls from lower level to higher level, as typically occurs in callbacks. Sep 14, 2017 at 23:25
  • This is a good answer, but it would be nice if you would elaborate on the 4 points, perhaps with some examples. Sep 15, 2017 at 5:07

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.


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.


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.

  • 1
    SOLID would mean you already blew it -- that is not good architecture, just cargo cult design. Sep 14, 2017 at 23:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.