A Heisenbug
Wikipedia defines a Heisenbug as:
A software bug that seems to disappear when one attempts to study it.
Sometimes one has these nightmare debugging sessions where you can prove that the bug can’t happen. But it still does. But I have rarely seen real Heisenbugs. Here is the story of one.
A Coworker once called me to his machine and showed our application and how it failed with a NullPointerException. Then he ran the application in the debugger, stepping through the code and the application just worked.
He could repeat this feat as often as he wanted. The perfect Heisenbug. So what was going on?
Well after a lot of really hard swearingthinking we found the following: The bug was caused by accessing the field of a property in a Hibernate entity directly, and not through its getter. So the field was lazy loaded and uninitialized and contained NULL, causing the NPE.
Why did it disappear in the debugger? There was an inspection showing the value returned by the getter. So on the first stop in the debugger the getter was called, Hibernate magic came to life, the field was populated and everything worked like a charm.
The moral of the story?
Don’t know. Software development sucks? Hibernate sucks?
Getters that modify object state suck!
I’ve seen the same problem with toStrings that trigger loading and thereby modify state.
Methods that look like simple property access but change state behind the scenes are evil.
@jessitron agree, but the evil one here is Hibernate convoluting simple accessors into mutators
Debugging sucks!
Hibernate and Relational Databases too, but this is another story. Hibernate solve some Problems and provide new. Remember it!
I’ve seen almost the same behavior in code generated by Thrift. On the one hand it produces public member variables and on the other it generates getters and setters, which modify state… just brilliant.