Recover usage in Go - Time & Space Complexity

Time Complexity: Recover usage

O(n)

Understanding Time Complexity

When using recover in Go, we want to know how it affects the program's speed.

We ask: does calling recover change how long the program takes as input grows?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

func safeDivide(nums []int, divisor int) []int {
    results := []int{}
    for _, num := range nums {
        func() {
            defer func() {
                if r := recover(); r != nil {
                    // handle division by zero
                }
            }()
            results = append(results, num/divisor)
        }()
    }
    return results
}
    

This code divides each number in a list by a divisor, using recover to handle any division by zero errors safely.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Looping through each number in the input slice.
• How many times: Once for each element in the input slice.

How Execution Grows With Input

As the input list gets bigger, the number of divisions and recover checks grows at the same pace.

Input Size (n)	Approx. Operations
10	About 10 divisions and recover checks
100	About 100 divisions and recover checks
1000	About 1000 divisions and recover checks

Pattern observation: The work grows directly with the number of items; doubling input doubles work.

Final Time Complexity

Time Complexity: O(n)

This means the time to run grows in a straight line with the input size.

Common Mistake

[X] Wrong: "Using recover inside the loop makes the code run slower exponentially."

[OK] Correct: Recover only runs when a panic happens, and the loop still runs once per item, so the time grows linearly, not exponentially.

Interview Connect

Understanding how recover affects time helps you write safe Go code without worrying about hidden slowdowns as your data grows.

Self-Check

What if we moved the recover call outside the loop? How would the time complexity change?

Practice

1. What is the main purpose of the recover function in Go?

easy

A. To handle errors returned by functions

B. To start a new goroutine

C. To pause the execution of a function

D. To catch a panic and prevent the program from crashing

Solution

1. Step 1: Understand panic and recover

   Panic causes a program to stop immediately unless recovered.

2. Step 2: Role of recover

   Recover catches the panic inside a deferred function to keep the program running.

3. Final Answer:

   To catch a panic and prevent the program from crashing -> Option D

4. Quick Check:

   recover catches panic = A [OK]

Hint: Recover catches panics only inside deferred functions [OK]

Common Mistakes:

• Thinking recover handles normal errors
• Using recover outside deferred functions
• Confusing recover with panic

2. Which of the following is the correct way to use recover in Go?

easy

A. Call recover directly inside the main function

B. Call recover inside a deferred function

C. Call recover inside a goroutine

D. Call recover after a panic has finished

Solution

1. Step 1: Identify recover usage rules

   Recover must be called inside a deferred function to catch panics.

2. Step 2: Analyze options

   Only Call recover inside a deferred function calls recover inside a deferred function.

3. Final Answer:

   Call recover inside a deferred function -> Option B

4. Quick Check:

   recover inside defer = B [OK]

Hint: Always use recover inside defer to catch panics safely [OK]

Common Mistakes:

• Calling recover directly without defer
• Calling recover after panic ends
• Using recover in goroutines without defer

3. What will be the output of this Go program?

package main
import "fmt"
func main() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered from panic:", r)
        }
    }()
    panic("something went wrong")
    fmt.Println("This will not print")
}

medium

A. Recovered from panic: something went wrong

B. something went wrong

C. This will not print

D. Program crashes with panic message

Solution

1. Step 1: Understand defer and recover behavior

   The deferred function runs after panic starts, calling recover to catch it.

2. Step 2: Output analysis

   Recover prints the panic message, so output is "Recovered from panic: something went wrong".

3. Final Answer:

   Recovered from panic: something went wrong -> Option A

4. Quick Check:

   defer + recover prints panic message = C [OK]

Hint: Recover prints panic message inside deferred function [OK]

Common Mistakes:

• Expecting code after panic to run
• Thinking panic message prints directly
• Ignoring deferred recover function

4. What is wrong with this Go code snippet?

func main() {
    recover()
    panic("error")
}

medium

A. panic() cannot be called without defer

B. panic() must be called before recover()

C. recover() is called outside a deferred function and will not catch panic

D. recover() cannot be called in main function

Solution

1. Step 1: Check recover usage

   Recover only works inside deferred functions to catch panics.

2. Step 2: Analyze code

   Recover is called directly, so it won't catch the panic, causing program to crash.

3. Final Answer:

   recover() is called outside a deferred function and will not catch panic -> Option C

4. Quick Check:

   recover outside defer = no panic catch = D [OK]

Hint: Recover must be inside defer to catch panic [OK]

Common Mistakes:

• Calling recover directly without defer
• Assuming recover catches panic anytime
• Misunderstanding panic and recover order

5. You want to safely handle panics in a function that divides two numbers and returns the result. Which code snippet correctly uses recover to avoid crashing when dividing by zero?

hard

A. func safeDivide(a, b int) int {
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered from panic")
}
}()
return a / b
}

B. func safeDivide(a, b int) int {
if b == 0 {
recover()
}
return a / b
}

C. func safeDivide(a, b int) int {
return a / b
defer recover()
}

D. func safeDivide(a, b int) int {
defer recover()
return a / b
}

Solution

1. Step 1: Identify correct recover usage

   Recover must be called inside a deferred anonymous function to catch panics.

2. Step 2: Analyze options

   Only func safeDivide(a, b int) int { defer func() { if r := recover(); r != nil { fmt.Println("Recovered from panic") } }() return a / b } uses defer with an anonymous function calling recover properly.

3. Final Answer:

   func safeDivide(a, b int) int { defer func() { if r := recover(); r != nil { fmt.Println("Recovered from panic") } }() return a / b } -> Option A

4. Quick Check:

   defer func with recover = safe panic handling = A [OK]

Hint: Use defer with anonymous func calling recover to catch panics [OK]

Common Mistakes:

• Calling recover without defer
• Calling recover outside anonymous function
• Placing defer after return statement