Returning Errors from Functions

Returning errors makes a function’s failure behavior explicit and lets callers decide whether to retry, explain or propagate a problem.

Give a function a result signature such as (int, error). On failure, return the result type’s zero value and a descriptive error; on success, return the computed value and nil.

At the call site, use the familiar early-return pattern if err != nil { ... }. Not every function needs an error result; reserve it for operations that can fail in an expected, meaningful way.

Follow this diagram before executing the example. Check where a value or decision changes what runs next.

This example is a complete program. Save it as main.go or paste it into the Go Playground.

Go code

package main

import (
	"errors"
	"fmt"
)

func divide(a, b int) (int, error) {
	if b == 0 {
		return 0, errors.New("cannot divide by zero")
	}
	return a / b, nil
}
func main() {
	answer, err := divide(12, 3)
	if err != nil {
		fmt.Println(err)
		return
	}
	fmt.Println("Quotient:", answer)
	_, err = divide(8, 0)
	if err != nil {
		fmt.Println("Failed:", err)
	}
}

Output

Quotient: 4
Failed: cannot divide by zero

The first call divides 12 by 3 and returns (4, nil). The second rejects a zero divisor and returns a descriptive non-nil error, which the caller prints.

• Check the error before treating a result as valid.
• Returning nil as an error should mean the function completed successfully under its contract.

Write a function that returns the first element of an int slice or an error when the slice is empty.

Tip: Edit the example above, predict the output, and run the modified code to test your reasoning.

You have practiced Returning Errors from Functions in a small, self-contained program. The important habit is to predict what runs, inspect the actual output and distinguish the language rule from the particular example.

Before continuing, make sure you can explain the program to someone who has not seen it, including the line that changes its result.