Lectures

We break down how to read a stack trace in Go as a “route map” to the bug: where to find the first line of your code ( file:line), how to interpret stack frames and the line goroutine 1 [running], and what the most common crashes mean: index out of range, slice bounds out of range, nil pointer dereference, integer divide by zero, assignment to entry in nil map, interface conversion. Separately — the role of defer during a panic and a practical diagnostic algorithm.

We break down two diagnostic tools in Go that look similar in form but differ in meaning: fast fmt.Printf-debugging as a “flashlight” to test hypotheses, and system logging via the log package as a “black box” of events. We compare fmt.Printf and log.Printf, discuss separating stdout/ stderr, a careful message style ( op=... key=...), and common mistakes like “forgotten debug prints” and overusing log.Fatal.

We break down debugging Go programs with Delve (the dlv command): why you need a debugger, how to set breakpoints, control execution via continue/ next/ step/ finish, inspect variable and expression values, and how to account for compiler optimizations (inlining) and test hypotheses on a mini-scenario with pointers.

We break down how to use Go tests as a “repeatable bug reproduction mode”: control execution via go test and the flags -run, -v, -count=1, target specific subtests ( TestXxx/subtest), build a minimal reproducible example ( MRE), and improve error messages with t.Helper().

A regression test is a “fuse” that prevents a bug you already fixed from showing up again: we make the problem reproducible, write a failing test, fix the code, and keep the test forever. In this lecture we break down the regression cycle, a Go example with panic/ recover(), a guard clause for len checks, a mustNotPanic helper, and also the rules: what exactly to lock in with a test (a result, an error, or the absence of a panic) and how to name such tests.