Run-time panics

Canonical guidance

• out-of-bounds indexing, nil dereference, invalid type assertions, and some channel misuse can panic
• these panics happen even when code never calls panic directly
• invariants and guards should make panic sites explainable

Use when

• reviewing crash risks
• hardening boundaries
• distinguishing expected errors from process-threatening failures

Avoid

• assuming only explicit panic calls matter
• leaving known panic sites to chance
• scattering recover broadly inside business logic

Preferred pattern

if i < 0 || i >= len(s) {
	return 0, false
}
return s[i], true

Anti-pattern

• indexing or dereferencing on a path where invalid input can reach runtime unchecked

Explanation: This is tempting when surrounding code “should” be correct, but unguarded panic sites deserve either proof or explicit handling.

Why

• agents reviewing Go need a reference page for operations that panic even without any explicit panic call in sight