Panic behavior in Go - Time & Space Complexity

Time Complexity: Panic behavior

O(n)

Understanding Time Complexity

When we look at panic behavior in Go, we want to understand how it affects the running time of a program.

Specifically, we ask: How does panicking change the number of steps the program takes?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

func process(items []int) {
    for _, item := range items {
        if item == 0 {
            panic("zero found")
        }
        // some processing
    }
}
    

This code loops through a list and panics if it finds a zero, stopping the program immediately.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Looping through the list of items.
• How many times: Up to the first zero found or all items if no zero.

How Execution Grows With Input

Execution grows with the number of items until a zero is found.

Input Size (n)	Approx. Operations
10	Up to 10 steps or fewer if zero found early
100	Up to 100 steps or fewer if zero found early
1000	Up to 1000 steps or fewer if zero found early

Pattern observation: The program stops early if a zero is found, so the work can be less than the input size.

Final Time Complexity

Time Complexity: O(n)

This means the program's running time grows linearly with the number of items, but it may stop sooner if a panic occurs.

Common Mistake

[X] Wrong: "Panic makes the program run slower for all items always."

[OK] Correct: Panic stops the program immediately, so it can actually reduce the work done, not increase it for all items.

Interview Connect

Understanding panic behavior helps you explain how error handling affects program flow and performance in real situations.

Self-Check

"What if we replaced panic with returning an error? How would the time complexity change?"

Practice

1. What happens when a panic is called in a Go program?

easy

A. The program ignores the panic and continues running.

B. The program restarts automatically.

C. The program stops immediately and prints an error message.

D. The program logs the error but continues execution.

Solution

1. Step 1: Understand panic behavior

   In Go, calling panic immediately stops normal execution and begins panicking.

2. Step 2: Effect on program flow

   The program prints a stack trace and error message, then terminates unless recovered.

3. Final Answer:

   The program stops immediately and prints an error message. -> Option C

4. Quick Check:

   Panic stops program = B [OK]

Hint: Panic always stops the program immediately [OK]

Common Mistakes:

• Thinking panic allows program to continue
• Confusing panic with error return
• Assuming panic restarts the program

2. Which of the following is the correct syntax to cause a panic with the message "error occurred"?

easy

A. panic("error occurred";)

B. panic("error occurred")

C. panic: "error occurred"

D. panic = "error occurred"

Solution

1. Step 1: Recall panic syntax

   Panic is a built-in function called with parentheses and a string argument.

2. Step 2: Check each option

   panic("error occurred") uses correct function call syntax. Others have invalid assignment, colon, or extra semicolon.

3. Final Answer:

   panic("error occurred") -> Option B

4. Quick Check:

   Panic is a function call = D [OK]

Hint: Panic is called like a function with parentheses [OK]

Common Mistakes:

• Using assignment instead of function call
• Adding extra semicolons inside panic call
• Using colon instead of parentheses

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

package main
import "fmt"
func main() {
    fmt.Println("Start")
    panic("something went wrong")
    fmt.Println("End")
}

medium

A. Start
End

B. something went wrong
panic stack trace

C. Start

D. Start
something went wrong
panic stack trace

Solution

1. Step 1: Trace program execution

   The program prints "Start" first, then calls panic with a message.

2. Step 2: Effect of panic on following code

   After panic, the program stops immediately, so "End" is not printed. Panic message and stack trace appear.

3. Final Answer:

   Start something went wrong panic stack trace -> Option D

4. Quick Check:

   Panic stops after printing Start = C [OK]

Hint: Panic prints message and stops; code after panic not run [OK]

Common Mistakes:

• Expecting code after panic to run
• Ignoring panic message output
• Confusing panic output with normal print

4. Identify the error in this Go code snippet:

func divide(a, b int) int {
    if b == 0 {
        panic("division by zero")
    }
    return a / b
}

func main() {
    result := divide(10, 0)
    fmt.Println(result)
}

medium

A. Missing import of "fmt" package

B. Cannot panic inside a function

C. Division by zero is allowed, no panic needed

D. Function divide should return error instead of int

Solution

1. Step 1: Check code for syntax errors

   The code uses fmt.Println but does not import "fmt" package.

2. Step 2: Validate panic usage

   Panic is allowed inside functions; division by zero should panic to avoid runtime error.

3. Final Answer:

   Missing import of "fmt" package -> Option A

4. Quick Check:

   Missing import causes compile error = A [OK]

Hint: Check imports when using fmt functions [OK]

Common Mistakes:

• Thinking panic is not allowed in functions
• Ignoring missing imports
• Assuming division by zero returns zero

5. You want to write a Go function that safely divides two integers and returns the result. If the divisor is zero, it should panic with "division by zero". Which of these implementations correctly uses panic and recover to handle the error and return zero instead of crashing the program?

func safeDivide(a, b int) int {
    // Your code here
}

func main() {
    fmt.Println(safeDivide(10, 0))
}

hard

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

B. func safeDivide(a, b int) int {
if b == 0 {
panic("division by zero")
}
return a / b
}

C. func safeDivide(a, b int) int {
defer func() {
if r := recover(); r != nil {
return 0
}
}()
if b == 0 {
panic("division by zero")
}
return a / b
}

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

Solution

1. Step 1: Understand panic and recover usage

   Recover must be called inside a deferred function to catch panic and prevent program crash.

2. Step 2: Analyze each option

   func safeDivide(a, b int) int { defer func() { if r := recover(); r != nil { fmt.Println("Recovered from panic") } }() if b == 0 { panic("division by zero") } return a / b } uses defer with recover to catch panic and prints a message, then continues. It returns the division result or panics if divisor is zero. func safeDivide(a, b int) int { defer func() { if r := recover(); r != nil { return 0 } }() if b == 0 { panic("division by zero") } return a / b } tries to return inside defer, which does not affect the outer function's return. func safeDivide(a, b int) int { if b == 0 { panic("division by zero") } return a / b } panics without recovery. func safeDivide(a, b int) int { if b == 0 { return 0 } return a / b } returns 0 without panic.

3. Final Answer:

   Option A correctly uses panic and recover to handle error and avoid crash. -> Option A

4. Quick Check:

   Defer recover catches panic = A [OK]

Hint: Use defer with recover to catch panic safely [OK]

Common Mistakes:

• Returning inside defer does not change function return
• Not using recover causes program crash
• Ignoring panic and returning zero silently