Fix Go 'multiple-value in single-value context' Error

beginner๐Ÿ”ท Go2026-03-17| Go 1.13+, any OS (Linux, macOS, Windows)

Error Message

multiple-value in single-value context
#go#function#return#error

The Error

./main.go:12:15: multiple-value in single-value context

Your build just blew up with this. The Go compiler is telling you that a function returning multiple values is being used where only one value is expected. Go is strict about this โ€” you can't silently ignore return values the way you can in Python or JavaScript.

Why This Happens

Most Go functions that can fail return (value, error). Go's compiler won't let you skip over return values. The moment you pass such a function's output directly into an expression, use it as a function argument, or assign it where only one value fits โ€” you get this error.

Common Scenario 1: Assignment mismatch

// WRONG โ€” os.Open returns (*File, error)
f := os.Open("config.json")

// RIGHT
f, err := os.Open("config.json")
if err != nil {
    log.Fatal(err)
}

Common Scenario 2: Passing multi-return function directly to another function

// WRONG โ€” strconv.Atoi returns (int, error)
fmt.Println(strconv.Atoi("42"))

// RIGHT
n, err := strconv.Atoi("42")
if err != nil {
    log.Fatal(err)
}
fmt.Println(n)

Common Scenario 3: Using multi-return in an expression

// WRONG
total := getValue() + 10

// If getValue() is defined as:
func getValue() (int, error) {
    return 42, nil
}

// RIGHT
val, err := getValue()
if err != nil {
    log.Fatal(err)
}
total := val + 10

Common Scenario 4: Nested function calls

// WRONG โ€” json.Marshal returns ([]byte, error)
os.Stdout.Write(json.Marshal(data))

// RIGHT
b, err := json.Marshal(data)
if err != nil {
    log.Fatal(err)
}
os.Stdout.Write(b)

Step-by-Step Fix

Step 1: Find the line causing the error

The compiler tells you the exact file and line:

./main.go:12:15: multiple-value in single-value context

Go to line 12, column 15. Look for a function call on the right-hand side.

Step 2: Check the function signature

Hover over the function in your editor or check the docs:

// Check what a function returns
go doc os.Open
// Output: func Open(name string) (*File, error)

Step 3: Capture all return values

Every return value needs a variable โ€” even the ones you don't plan to use:

// Use blank identifier _ to discard a value you don't need
f, _ := os.Open("config.json")

That said, discarding errors in production code is usually a bad idea. The blank identifier is fine for quick scripts or when you're absolutely certain an error won't occur.

Step 4: Restructure the code

When the multi-return call is buried inside an expression, pull it out first:

// Before (broken)
result := process(strconv.Atoi(input))

// After (fixed)
n, err := strconv.Atoi(input)
if err != nil {
    return fmt.Errorf("invalid input: %w", err)
}
result := process(n)

Special Case: Functions Returning Multiple Non-Error Values

Not every multi-return function involves errors. Sometimes you have something like:

func minMax(nums []int) (int, int) {
    // ...
    return min, max
}

// WRONG
fmt.Println("Min:", minMax(nums))

// RIGHT
min, max := minMax(nums)
fmt.Println("Min:", min, "Max:", max)

Go does allow passing a multi-return function directly to another function only if the receiving function's parameter list matches exactly. This is rare and generally avoided for readability โ€” explicit variable names make the code much easier to follow.

Verify the Fix

go build ./...

A clean build outputs nothing. You can also run:

go vet ./...

to catch any other type-related issues before shipping.

Tips to Avoid This in the Future

  • Use an IDE with Go support โ€” GoLand or VS Code with the Go extension flags this error before you even save the file.
  • Enable golangci-lint in your CI pipeline. It catches this and dozens of similar issues automatically.
  • Never chain multi-return functions โ€” always assign to named variables first, even if it adds a line. Your future self debugging at 2 AM will thank you.
  • The blank identifier is a last resort โ€” if you're discarding an error with _, add a comment explaining why it's safe to ignore.

Related Error Notes