Lectures

In this lecture we will break down Go’s standard error wrapping mechanism: how adding context via %v differs from real wrapping via %w in fmt.Errorf, how the cause chain is structured, how errors.Unwrap works, and how to apply it in practice in a simple CLI. At the end, we’ll review typical mistakes when using wrapping.

We break down how to correctly check and classify errors in Go without parsing error text: why you should not build logic on err. Error(), how wrapping via "%w" works, how errors.Is (checking “that exact cause”) differs from errors.As (finding an error of the needed type and extracting details), and also common mistakes: comparing with == after wrapping, using "%v" instead of "%w", and passing & target incorrectly to errors.As.

In this lecture, we will cover two main “recognizable” approaches to errors in Go: sentinel (marker) errors and typed errors. We will learn how to design an error-handling contract using errors.Is and errors.As, discuss wrapping via fmt.Errorf with "%w", see the risks of “leaking implementation details”, and assemble a practical mixed design: sentinel class + typed cause (including via errors.Join).

Let’s break down why in Go you sometimes need to return several errors at once, how errors.Join works (Go 1. 20+), why this is not “string concatenation” but a structured multi-error, and how it affects UX. We’ll build patterns for validation (with sentinel errors and context via fmt.Errorf using "%w") and for data import with accumulated per-line errors. We’ll also discuss how errors.Is/ errors.As keep working with joined errors, and what typical mistakes happen when using errors.Join.

Let's break down a practical approach to an error "taxonomy" in Go: how to выделить a small set of error classes (for example, validation/ notfound/ io/ internal), mark them with sentinel errors, wrap causes via %w, combine causes with labels via errors. Join, and choose top-level behavior using errors. Is.