golang-error-handlinglisted

# Go Error Handling Treat errors as part of the API. Preserve enough identity and context for the owner to act, without leaking secrets or coupling callers to accidental implementation details. ## Inspect the existing contract Before editing: 1. Read repository conventions, public documentation, tests, and callers using `errors.Is` or `errors.As`. 2. Identify the layer that can decide retry, fallback, user response, process exit, or logging. 3. Separate expected domain outcomes from infrastructure failures and programmer defects. 4. Preserve stable sentinels, types, status mappings, and wire responses unless changing the contract is requested. ## Propagate useful information Check errors unless the API documents that they are ignorable and the code explains why. Add wrapping context when it identifies the failed operation or boundary: ```go value, err := store.Load(ctx, id) if err != nil { return Item{}, fmt.Errorf("loading item %q: %w", id, err) } ``` Do not wrap at every stack frame mechanically; repeated “failed to” prefixes add noise. Use `%w` only when exposing the wrapped error's identity is part of the intended contract. At a public or trust boundary, translate to a stable domain or transport error instead of assuming `%v` makes the message safe—it breaks unwrapping but still includes the original text. Use `errors.Is` for semantic matching through a chain and `errors.As` for typed detail. Avoid direct equality or type assertions when wrapping is allowed.