Error interface in Go - Step-by-Step Execution

Concept Flow - Error interface

Start

↓

Call function returning error

↓

Check if error is nil

↓

Handle error

↓

End

This flow shows how Go functions return errors and how to check and handle them.

Execution Sample

Go

package main
import (
 "errors"
 "fmt"
)
func doTask() error {
 return errors.New("something went wrong")
}
func main() {
 err := doTask()
 if err != nil {
  fmt.Println("Error:", err)
 } else {
  fmt.Println("Success")
 }
}

This code defines a function that returns an error and main checks and prints the error if present.

Execution Table

Step	Action	Evaluation	Result
1	Call doTask()	doTask() returns error	error with message 'something went wrong'
2	Assign error to err	err = error object	err holds error
3	Check if err != nil	err is not nil	Condition true
4	Print error message	fmt.Println("Error:", err)	Output: Error: something went wrong
5	End program	No further code	Program terminates

💡 Program ends after printing the error message because err was not nil

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
err	nil	error object created	error object assigned	error object checked (not nil)	error object held

Key Moments - 3 Insights

Why do we check if err != nil before using err?

Because err is nil when there is no error, so checking err != nil ensures we only handle errors when they actually exist, as shown in step 3 of the execution_table.

What does errors.New("something went wrong") do?

It creates a new error object with the message 'something went wrong', which is returned by doTask() in step 1.

Why do we print err directly instead of err.Error()?

Printing err calls its Error() method automatically, so fmt.Println("Error:", err) prints the error message, as seen in step 4.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of err after step 2?

A nil

B empty string

C error object with message 'something went wrong'

D boolean false

💡 Hint

Check the 'After Step 2' column in variable_tracker for err

At which step does the program decide to print the error message?

A Step 3

B Step 4

C Step 1

D Step 5

💡 Hint

Look at the 'Action' and 'Result' columns in execution_table

If doTask() returned nil instead of an error, what would happen at step 3?

A Condition err != nil would be false

B Condition err != nil would be true

C Program would crash

D Error message would print anyway

💡 Hint

Refer to the 'Check if err != nil' row in execution_table and understand nil means no error

Concept Snapshot

Error interface in Go:
- Functions return error type to signal problems.
- Check if error is nil before handling.
- Use errors.New() to create errors.
- Print error directly calls Error() method.
- Always handle errors to avoid silent failures.

Full Transcript

This visual execution traces how Go's error interface works. The function doTask returns an error created by errors.New. The main function assigns this error to variable err. It then checks if err is not nil, meaning an error occurred. Since err holds an error, the program prints the error message. If err were nil, it would print success instead. This shows the common pattern of error handling in Go: call function, check error, handle error or continue. Variables and conditions are tracked step-by-step to clarify the flow.

Practice

1.

What does the Error() method in Go's error interface return?

easy

A. A boolean indicating success or failure

B. An integer error code

C. A string describing the error message

D. A pointer to the error object

Solution

1. Step 1: Understand the error interface

   The error interface in Go defines a single method Error() that returns a string.

2. Step 2: Identify the return type of Error()

   The Error() method returns a string that describes the error message.

3. Final Answer:

   A string describing the error message -> Option C

4. Quick Check:

   Error() returns string message [OK]

Hint: Error() always returns a string message describing the problem [OK]

Common Mistakes:

• Thinking Error() returns an integer code
• Assuming Error() returns a boolean
• Confusing Error() with returning an error object pointer

2.

Which of the following is the correct way to declare a function in Go that returns an error?

func doSomething() ???

easy

A. func doSomething() error

B. func doSomething() string

C. func doSomething() (int, error)

D. func doSomething() *error

Solution

1. Step 1: Recall function return types for errors

   In Go, functions that can fail often return an error type as the last return value.

2. Step 2: Check the syntax for returning only an error

   The correct syntax for a function returning only an error is func doSomething() error.

3. Final Answer:

   func doSomething() error -> Option A

4. Quick Check:

   Function returns error type only [OK]

Hint: Use 'error' as return type to indicate possible failure [OK]

Common Mistakes:

• Returning *error instead of error
• Returning string instead of error
• Returning multiple values without parentheses

3.

What will be the output of the following Go program?

package main
import (
	"errors"
	"fmt"
)
func main() {
	err := errors.New("file not found")
	if err != nil {
		fmt.Println(err.Error())
	} else {
		fmt.Println("No error")
	}
}

medium

A. file not found

B. No error

C. nil

D. Compilation error

Solution

1. Step 1: Understand errors.New usage

   The errors.New function creates a new error with the message "file not found".

2. Step 2: Check the if condition and output

   Since err is not nil, the program prints err.Error(), which is the string "file not found".

3. Final Answer:

   file not found -> Option A

4. Quick Check:

   Non-nil error prints message [OK]

Hint: errors.New creates error with message; err != nil prints message [OK]

Common Mistakes:

• Expecting 'No error' output
• Thinking err is nil after errors.New
• Confusing err.Error() with err itself

4.

Identify the error in this Go code snippet:

func check() error {
	var err error
	if err != nil {
		return err
	}
	return nil
}

medium

A. Missing parentheses in if condition

B. Variable err is never assigned, so err != nil is always false

C. Function must return a string, not error

D. Cannot return nil from a function returning error

Solution

1. Step 1: Analyze variable initialization

   The variable err is declared but never assigned a value, so it defaults to nil.

2. Step 2: Evaluate the if condition

   Since err is nil, the condition err != nil is false, so the return inside if never runs.

3. Final Answer:

   Variable err is never assigned, so err != nil is always false -> Option B

4. Quick Check:

   Unassigned error variable is nil [OK]

Hint: Uninitialized error is nil, so err != nil is false [OK]

Common Mistakes:

• Assuming err is non-nil by default
• Thinking function must return string
• Confusing nil return with error

5.

Given this Go function that returns an error, how can you modify it to wrap the original error with additional context?

func readFile() error {
	return errors.New("file missing")
}

Choose the best way to add context "readFile failed:" before the original error message.

hard

A. return fmt.Errorf("readFile failed: %v", errors.New("file missing"))

B. return errors.New("readFile failed: file missing")

C. return errors.Wrap(errors.New("file missing"), "readFile failed")

D. return fmt.Errorf("readFile failed: %w", errors.New("file missing"))

Solution

1. Step 1: Understand error wrapping in Go

   Go 1.13+ supports error wrapping using fmt.Errorf with the %w verb to wrap an error with context.

2. Step 2: Check options for wrapping

   return fmt.Errorf("readFile failed: %w", errors.New("file missing")) uses fmt.Errorf("readFile failed: %w", errors.New("file missing")), which correctly wraps the original error with context.

3. Step 3: Identify incorrect options

   return errors.New("readFile failed: file missing") creates a new error string but does not wrap the original error. return errors.Wrap(errors.New("file missing"), "readFile failed") uses errors.Wrap which is not in standard Go. return fmt.Errorf("readFile failed: %v", errors.New("file missing")) uses %v which formats but does not wrap the error.

4. Final Answer:

   return fmt.Errorf("readFile failed: %w", errors.New("file missing")) -> Option D

5. Quick Check:

   Use fmt.Errorf with %w to wrap errors [OK]

Hint: Use fmt.Errorf with %w to wrap errors and add context [OK]

Common Mistakes:

• Using %v instead of %w for wrapping
• Creating new error string without wrapping
• Using non-standard errors.Wrap function