How does Go handle multiple return values, and what are named returns?
Go functions can return multiple values natively, which is the idiomatic way to return both a result and an error. Named returns pre-declare result variables in the function signature.
Multiple return values are a first-class feature in Go, most commonly used for the (result, error) pattern. This makes error handling explicit and visible at every call site.
- 1
Named returns improve readability in short functions by documenting what each return value represents
- 2
Allow bare return statements — return without arguments uses the named variables
- 3
Can be used with defer to modify return values after the function body executes
- 4
Avoid in long functions — bare returns hide what is actually being returned and hurt readability
- 5
Named returns are especially useful for defer-based cleanup that modifies error return
Scenario Questions
0-2 years experience
- 1Write a function that takes two ints and returns both their sum and product. How would you call it and capture the results?
- 2If a function is declared as `func fetch() (data []byte, err error)`, what values are returned when you use a bare `return` inside the function?
- 3What happens if you assign the results of a multiple‑return function to a single variable without using the blank identifier?
2-5 years experience
- 1You added a helper that returns a value and an error using named returns. After integration a nil‑pointer panic occurs when the caller ignores the error. Walk me through how you’d debug this and what the named return semantics imply.
- 2Explain why refactoring `func parse(s string) (int, error)` to `func parse(s string) (result int, err error)` introduced a subtle bug in a loop that aggregates results.
- 3When calling a function that returns three values, you only need the first and third. Show the call syntax and discuss any performance impact of discarding the second value.
5-8 years experience
- 1In a high‑throughput microservice, a function returns a result struct and an error. Discuss the trade‑offs of using named return values versus explicit returns for readability and hidden bugs, especially with defer statements.
- 2Design a pattern for propagating errors through several layers of calls without losing context, using multiple return values and named returns. How would you preserve stack traces?
- 3Your team wants to standardize on named returns for all functions that return errors. What are the pros and cons at scale, and how would you mitigate risks like accidental zero‑value returns?
8+ years experience
- 1A legacy codebase mixes unnamed and named returns inconsistently, causing confusion during a large refactor. Propose a migration strategy that balances developer velocity and code clarity, including any tooling or lint rules.
- 2When designing a public Go SDK for many teams, how would you decide whether to expose functions with multiple unnamed returns or a single struct return, considering versioning and backward compatibility?
- 3Discuss how named return parameters interact with defer and recover in a distributed system that must guarantee resource cleanup even when errors are returned. What architectural guidelines would you set?
Follow-up Questions
- What edge cases do you need to guard against when using named returns?
- How does a bare return interact with deferred functions?
- Would you ever prefer a single struct over multiple return values? Why?