Ifference Between Returning Err And Wrapping It
Fast recall
Quick revision
Core answer
Practical understanding of If Err Not Nil Pattern.
Repeating a definition without saying when to use it.
Give one trade-off and say how you would test it.
Interview-ready guide
Interview answer
The blank identifier is Go's escape valve for unused returns, and errors are where it matters most:
_, err := f() // need only the error — fine, common
v, _ := f() // take the value, ignore the error — the dangerous onev, _ is legal Go and sometimes correct — best-effort writes, metrics, caches where failure changes nothing. The _ documents the decision at the call site: a reader sees the error was considered and dropped, not overlooked.
But most v, _ in real code is a latent bug. The failure doesn't vanish — it moves downstream. The zero value gets used, and the cause becomes 'why is this empty?' three weeks later. No compile error, no test failure — the error was already gone at the point where it could have been handled.
That's why errcheck exists as a linter: the language permits discarding, the ecosystem flags it. The alternatives in order of effort: log it (v, err := f(); if err != nil { log... } — three lines, failure becomes diagnosable), handle it, or propagate it. Reach for _ only when you can say why the error doesn't matter — out loud, at that line.
Ifference Between Returning Err And Wrapping It
Direct Answer
_, err := f() keeps only the error. v, _ := f() discards the error — a lint smell unless failure is genuinely impossible. _ makes ignoring an explicit choice.
Deep Dive & Architecture
_ is the only way to opt out of a return value in Go, and its error-slot usage divides into three patterns of very different health:
-
_, err := f()— want the error only. Common and correct: existence checks, did-it-succeed calls. Nothing lost. -
v, _ := f()— want the value only. The dangerous one. The error is gone at the moment it occurred; the zero value flows onward. The failure isn't handled — it's POSTPONED, to wherever the zero value misbehaves. That indirection is what makes these bugs hard: the crash site is three functions away from the cause site. -
A bare
f()— only legal when f returns nothing. When f returns an error, the call alone doesn't compile — Go requires the assignment shape for multi-return, which is precisely why _ exists: the language makes ignoring a DECISION — you type it.
That's the design insight: languages without this forcing function let failures disappear silently (unchecked exceptions, ignored return codes via lint-only warnings). Go makes ignore an explicit token at the exact line — so code review can catch it, linters can flag it, and the reader can ask 'why?'. The errcheck linter exists because reviewers asked it enough. The rule that survives review: every _ on an error slot carries a justifying comment — or it doesn't survive.
Common Mistakes & Pitfalls
Repeating a definition without saying when to use it.
Check your understanding
Answer these without looking back at the article.
- What is If Err Not Nil Pattern, and when would you use it?
- When would you use If Err Not Nil Pattern in a real project?
- What is a common mistake when using If Err Not Nil Pattern?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.