Challenge 2: An Intermittent, Hard-to-Reproduce Bug — Solution Walkthrough

An alternative approach:

Set a breakpoint at the point in the code most likely involved in the
bug, run in Debug mode, and wait for the app to naturally hit that
breakpoint whenever the intermittent condition actually occurs —
rather than adding several Log statements and repeatedly rerunning the
app hoping one of them captures the right information.

Why this can be more effective specifically here:

Per this chapter's own warning box, the core problem with a Log-and-
rerun approach for an intermittent bug is having to guess in advance
exactly what to log before the bug actually happens again — if the
wrong values were logged, or a relevant piece of state wasn't logged
at all, an entire rerun is wasted waiting for the bug to reoccur.
Once a breakpoint actually pauses execution at the exact moment
something related to the bug occurs, the Variables pane and Evaluate
Expression let you inspect anything in scope at that exact moment,
including things nobody thought to add a Log statement for ahead of
time — no need to have predicted the right variables to log in
advance.

Why this matters more for an intermittent bug specifically:

A reliably-reproducible bug can afford several rerun cycles cheaply,
since each rerun reliably triggers it again. An intermittent bug makes
each wasted rerun (from having logged the wrong thing) considerably
more costly, since there's no guarantee the next rerun will even
reproduce the issue at all — making the breakpoint's "inspect anything,
decide afterward" flexibility especially valuable here.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise applies this chapter's own warning box to the specific
scenario it was written for — an intermittent, hard-to-reproduce bug —
correctly explaining why the debugger's flexibility matters even more
here than for an easily-reproducible issue.