Lectures

We break down defer in Go: why it is useful with multiple returns, when deferred calls run, why arguments are captured immediately, and why the calls themselves execute in LIFO order. With examples, we will see pitfalls with loops and closures, and build a simple mental model of the “defer stack” so you can predict output without surprises.

We break down how to reliably release resources in Go using defer: the correct order “acquire → check err → schedule cleanup”, why it is important not to forget Close () and Unlock (), what to do with an error from Close (), when errors.Join is appropriate, and what pitfalls await when using defer inside loops.

In Go, we break down the difference between panic and error: which problems are considered “expected” and should be returned as errors, and which ones indicate a broken invariant and may justify a panic. Using a learning example of a CLI calculator, we will reinforce the (T, error) contract, look at common runtime panics (slices, nil map, division by zero), and discuss where the Must style fits.

We break down how recover() works in Go and why it only makes sense inside defer: how to catch panic at the application boundary, build a safe main pattern via safeRun(), convert a panic value into a neat error, and (if needed) print a stack trace using debug.Stack(). At the end, we cover common mistakes when using panic/ recover.

We break down where recover is truly appropriate in Go: why it should be placed only at the application boundary (often in main()/ safeRun()), how to distinguish expected errors ( error) from “impossible” situations ( panic), and why recover inside business logic turns into a dangerous anti-pattern. At the end, there’s a practical checklist and common mistakes.