I’ve been doing a lot of work on startup anti-patterns recently so it seems fitting that I look at other things through that lens.
Every few months I fall into the same debugging anti-pattern:
- I start using a debugger to track down a difficult-to-pin-down issue.
- I set up a watch expression to look at some complex data structure.
- The debugger evaluates the watch expression outside its intended scope, which (sometimes) creates a side effect that cannot be observed directly at the time it happens.
one_tricky_problem + one_semi_random_problem == frustration
Yesterday, it happened when I was debugging a VBA script that’s part of my automation of tax preparation. Don’t ask: it seemed like a good idea a long time ago and is probably the main reason I occasionally use my old Windows machine.
The VBA Dictionary class will auto-create elements for any key it doesn’t have a value for. Therefore, a watch expression such as:
can easily create a Nothing value with an Empty key when myClass is in scope and when myKey is a Variant not in scope.
The previous time I experienced a similar problem was in Ruby when the watch expression had a side-effect on a cache whose logic I was trying to debug.
Eventually, I hope to develop a sixth sense for this debugging anti-pattern. In the meantime, I don’t like my options: (a) not use a debugger or (b) live with paranoia about watch expressions.
Alternatively, I could embrace functional programming languages without side effects. I wonder what their debuggers are like…