Loading…
Goroutines, channels, interfaces, error handling and the idioms Go reviewers care about.
A teammate adds request timing to an order handler:
func handleOrder(id string) {
A function opens a database transaction, then a file, then takes a mutex, deferring the release of each right after acquiring it. In what order do the deferred calls run, and why is that order the right one for cleanup?
In a payment service, when is it reasonable to call panic, and when
should a function return an error instead? Give an example of each
from code you might actually write.
Review this export function:
func exportInvoices(path string, rows []Invoice) error {
A developer coming from Java asks why Go functions return
(value, error) instead of throwing exceptions, and whether it is
fine to use the value when err != nil. Explain Go's approach and
the usual pattern for handling the result.
Your storage package needs callers to be able to tell "record not
found" apart from other failures. A colleague suggests callers check
strings.Contains(err.Error(), "not found"). What is a sentinel
error, how should callers check for one, and why is the string check