ProgramGuru

Panic vs Error

Start with Panic vs Error

Errors report anticipated failure conditions through normal control flow; panics signal a different, exceptional interruption.

What you’ll learn

  • Explain the main purpose of panic vs error.
  • Read and run the complete Go example in this lesson.
  • Apply the concept and recognize common mistakes.

Understand the idea

Invalid user input, failed file access and unavailable network dependencies should usually be returned as errors so a caller can decide what to do. A panic can be appropriate when an internal invariant is broken and normal continuation is unsafe.

The difference concerns the contract, not simply how serious a message sounds. The example intentionally uses an error for invalid data and shows both successful and failing inputs without crashing.

Visualize how it works

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

Visual explanation for panic vs errorA condition branches into true or false paths before continuing.Expected invalid input?TRUEFALSEReturn errorExceptional invariant?Consider panic only if justified
Trace control flow in the order shown, then compare it with the program.

Run a complete Go example

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 ticketCount(n int) (int, error) {
	if n < 0 {
		return 0, errors.New("negative ticket count")
	}
	return n, nil
}
func main() {
	for _, n := range []int{3, -1} {
		count, err := ticketCount(n)
		if err != nil {
			fmt.Println("Rejected:", err)
			continue
		}
		fmt.Println("Accepted:", count)
	}
}

Output

Accepted: 3
Rejected: negative ticket count

Trace what the program does

A count of 3 is accepted and printed. A negative count returns an error, so the loop reports rejection and continues safely rather than panicking.

Avoid common mistakes

  • Do not use panic as an ordinary alternative to returning an error for bad input.
  • Do not recover every panic and silently pretend an operation succeeded.

Try it yourself

Write a function that rejects an empty name through an error result. Call it with a valid and empty string.

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

Check your understanding

How should a normal invalid-input failure usually be reported?
Choose one answer. You can try again.

Answer and explanation

Return an error

Correct. A count of 3 is accepted and printed.

What you should remember

You have practiced Panic vs Error 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.

Reaching the recap and completing the quizzes are separate milestones.

    Next lesson: Error Handling Best Practices →