go/ignored-errors

Ignored errors. `_ = err`, unchecked returns, or `err` shadowed and never handled. Every error is handled, returned wrapped (`fmt.Errorf("...: %w", err)`), or explicitly justified.

Read it in the terminal

The same facts, from the checkout you are already in — no browser, and no network.

$ npx redlinegate explain go/ignored-errors

Where this came from

You are most likely here from a review comment. A finding names its rule and, when your repository has told Redline where the standard is published, its address:

Redline/BLOCKER [go/ignored-errors]: …
  → …/r/go/ignored-errors

That second line is written by redline init --docs-url and is empty until an organisation sets one — there is no default, because a link to somebody else's copy of the standard is worse than no link. See Onboard a repository.

In context

The Go standard lists this rule with the rest of its stack, in the file a reviewer and an AI assistant both read.

Other BLOCKER rules in this stack

• go/goroutine-leaksGoroutine leaks. Goroutine started without a way to stop: missing context cancellation, blocked forever on channel send/receive, no `WaitGroup`/errgroup ownership.
• go/missing-ctx-propagationMissing `ctx` propagation. Outbound calls (HTTP, DB, gRPC) must take the request's `context.Context`; no `context.Background()` inside request handling.
• go/data-racesData races. Shared map/slice/struct written from multiple goroutines without mutex or channel ownership; loop variable captured by reference in goroutine (pre-1.22 semantics or when version unknown).
• go/writing-nil-mapWriting to a nil map.
• go/copying-sync-primitiveCopying a struct containing `sync.Mutex`/`sync.WaitGroup` (passing by value, range over slice of them).
• go/defer-in-loop`defer` in a loop for per-iteration resources (files, rows, locks) — defers pile up until function exit; extract loop body into a function.