Lectures

We break down what any is (an alias for interface {}), why it’s “flexibility at the price of surprises”, where any fits (application boundaries, logging, generic containers), and where it breaks your model and creates hidden contracts. Separately, we discuss the nil trap inside an interface and the risks of map[any]... with non-comparable keys.

We break down how to safely “pull out” a concrete type from an interface in Go via type assertion v , ok := x .( T ): when you need the ok check, why the form without ok is dangerous (panic), how to verify behavior via interfaces ( fmt.Stringer, “temporary” errors), and what pitfalls are related to T vs *T and nil. At the end: typical mistakes and readability criteria.

We break down how to use type switch in Go to branch on the actual dynamic type of a value stored inside an interface ( any, error): the syntax switch x .( type ), command dispatching, handling multiple types in a single case, interface-based branches (for example, fmt.Stringer), the case nil vs typed nil trap, why branch order matters, and common mistakes.

We break down why Go needs typed errors (struct-based errors), how to design their fields and the Error() method, how value receivers and pointer receivers differ when implementing the error interface, and how to wrap underlying causes correctly via Unwrap() so that errors.Is and errors.As work. We build an error chain using a mini app example (“tasker”) and discuss common design mistakes.

We break down how, at the application boundary (CLI/HTTP), to turn any error into a stable UX message without losing diagnostic context: wrapping with fmt.Errorf using %w, the cause chain via Unwrap(), searching for typed errors with errors.As (and why & target is required), plus an example mini task tracker with ValidationError, OpError, NotFoundError, and conversion to UserError.