Lectures

We break down why error in Go is an interface, how the contract err == nil (success) and err != nil (error) works, how fmt prints errors via the Error() method, why you must not build logic based on the text of err. Error(), and what this looks like in practice with strconv. Atoi. At the end — a mini app “Expense tracking”, a mermaid flow diagram, and typical beginner mistakes.

We break down why in Go it’s customary to return errors rather than print them inside functions, and how to create errors using errors . New ( "..." ) and fmt . Errorf ( "..." , x ). We’ll talk about returning zero value in the signature ( T , error ), adding context to someone else’s errors via fmt . Errorf (without %w), and we’ll build a mini calculator with validation. At the end — common mistakes and how to avoid them.

We break down the philosophy and practice of error handling in Go: why the idiom if err != nil shows up everywhere, how an early return makes code linear and readable (a happy path without nesting), what to return from functions with the contract ( T , error ) and why you need a zero value. We will also show adding context via fmt. Errorf without %w, the run () error pattern for a “thin” main (), an example mini-app TaskBox, and a set of micro-patterns/anti-patterns.

We break down the “Go-ish” style of error messages: why the error text is a public interface of the error type, how to write messages in lowercase and without a period, why you don’t need the "Error:" prefix, how to build chains in the "operation: reason" format, how to add context via fmt. Errorf (), and which details (for example, %q, %d) help make errors useful in logs and tests.

We break down how to design function contracts in Go: when it makes sense to return bool (predicates), when (T, bool) is better (lookup/get without “magic values”), and when you need error or (T, error) (the reason for failure matters). Using TodoLite examples, we compare the semantics of “not found” vs “error”, collect selection criteria into a table, and lock the decision in with a flowchart (mermaid). Finally, we cover typical mistakes when choosing a contract and how to avoid them.