Exception hierarchy in Ruby - Step-by-Step Execution

Concept Flow - Exception hierarchy

Start

↓

Raise Exception

↓

Check Exception Type

↓

Is it StandardError?

Yes→Handle StandardError

↓

Is it Exception?

Yes→Handle Exception

↓

Unhandled Exception

↓

End

When an exception is raised, Ruby checks its type against the hierarchy from StandardError down to Exception, handling it if matched or leaving unhandled otherwise.

Execution Sample

Ruby

begin
  raise ZeroDivisionError, "divided by zero"
rescue StandardError => e
  puts e.class
end

This code raises a ZeroDivisionError and rescues it as a StandardError, printing the exception class.

Execution Table

Step	Action	Exception Raised	Exception Type Checked	Handled?	Output
1	Begin block starts	None	None	No
2	Raise ZeroDivisionError	ZeroDivisionError	Is it StandardError?	Yes
3	Rescue block catches exception	ZeroDivisionError	Handled as StandardError	Yes	ZeroDivisionError
4	End of begin-rescue block	None	None	No

💡 Exception ZeroDivisionError is a subclass of StandardError, so it is handled and output is printed.

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
e	nil	ZeroDivisionError instance	ZeroDivisionError instance	ZeroDivisionError instance

Key Moments - 2 Insights

Why does rescuing StandardError catch ZeroDivisionError?

Because ZeroDivisionError is a subclass of StandardError, as shown in execution_table step 2 and 3, so the rescue matches it.

What happens if an exception is not a StandardError subclass?

It is not caught by rescue StandardError and will be unhandled, as the flow shows in the concept_flow after checking StandardError.

Visual Quiz - 3 Questions

Look at the execution_table at step 2, which exception type is raised?

A Exception

B StandardError

C ZeroDivisionError

D RuntimeError

💡 Hint

Check the 'Exception Raised' column at step 2 in the execution_table.

At which step is the exception handled in the execution_table?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look for 'Handled?' column with 'Yes' and output printed.

If we raise an exception not inheriting from StandardError, what happens?

A It is unhandled and causes program to crash

B It is automatically converted to StandardError

C It is handled by rescue StandardError

D It is ignored silently

💡 Hint

Refer to concept_flow where exceptions not matching StandardError are unhandled.

Concept Snapshot

Exception hierarchy in Ruby:
- Exception is the root class
- StandardError is a common subclass
- rescue without args catches StandardError and subclasses
- Specific exceptions inherit from StandardError
- Exceptions outside StandardError are not caught by default rescue
- Use rescue Exception to catch all exceptions (not recommended)

Full Transcript

This visual execution shows how Ruby handles exceptions using its hierarchy. When an exception like ZeroDivisionError is raised, Ruby checks if it is a subclass of StandardError. Since it is, the rescue block catches it and prints the exception class. If an exception is not a StandardError subclass, it remains unhandled and may crash the program. This hierarchy helps organize error handling in Ruby programs.

Practice

1.

Which class is the root of the exception hierarchy in Ruby?

easy

A. RuntimeError

B. StandardError

C. Exception

D. IOError

Solution

1. Step 1: Understand Ruby's exception hierarchy

   In Ruby, all exceptions inherit from the Exception class, which is the root of the hierarchy.

2. Step 2: Identify the root class

   Other exception classes like StandardError and RuntimeError are subclasses of Exception.

3. Final Answer:

   Exception -> Option C

4. Quick Check:

   Root exception class = Exception [OK]

Hint: Remember: all errors come from Exception root [OK]

Common Mistakes:

• Confusing StandardError as root
• Thinking RuntimeError is root
• Choosing specific error classes instead of root

2.

Which of the following is the correct way to rescue only StandardError exceptions in Ruby?

begin
  # some code
rescue ???
  puts 'Error caught'
end

easy

A. StandardError

B. Exception

C. RuntimeError

D. IOError

Solution

1. Step 1: Understand rescue syntax

   The rescue keyword can specify which exception class to catch by naming it after rescue.

2. Step 2: Choose the correct exception class

   To catch only StandardError exceptions, write rescue StandardError.

3. Final Answer:

   StandardError -> Option A

4. Quick Check:

   Rescue specific error = StandardError [OK]

Hint: Use rescue with exact error class name [OK]

Common Mistakes:

• Using Exception catches too many errors
• Using RuntimeError misses other StandardErrors
• Using IOError catches unrelated errors

3.

What will be the output of this Ruby code?

begin
  raise IOError, 'File error'
rescue StandardError => e
  puts e.class
end

medium

A. StandardError

B. Exception

C. RuntimeError

D. IOError

Solution

1. Step 1: Identify the raised exception

   The code raises an IOError with message 'File error'.

2. Step 2: Check rescue clause

   The rescue catches StandardError and its subclasses. IOError is a subclass of StandardError, so it is caught.

3. Step 3: Output the exception class

   The code prints e.class, which is IOError.

4. Final Answer:

   IOError -> Option D

5. Quick Check:

   Raised error class = IOError [OK]

Hint: Raised error class prints even if rescued [OK]

Common Mistakes:

• Assuming rescue prints StandardError
• Confusing Exception with StandardError
• Thinking RuntimeError is printed

4.

Find the error in this Ruby code snippet:

begin
  raise 'Oops!'
rescue IOError
  puts 'IO error caught'
end

medium

A. The raise statement must specify an exception class

B. The rescue clause will not catch the raised error

C. The rescue clause syntax is incorrect

D. No error; code runs fine

Solution

1. Step 1: Analyze the raised error

   Raising with a string 'Oops!' creates a RuntimeError by default.

2. Step 2: Check rescue clause type

   The rescue only catches IOError, but the raised error is RuntimeError, so it is not caught.

3. Final Answer:

   The rescue clause will not catch the raised error -> Option B

4. Quick Check:

   Rescue type mismatch causes uncaught error [OK]

Hint: Raised error type must match rescue type [OK]

Common Mistakes:

• Thinking rescue catches all errors by default
• Believing string raise is invalid syntax
• Assuming rescue syntax is wrong

5.

You want to catch all exceptions except system-exiting ones like SystemExit and Interrupt. Which class should you rescue to catch most errors but allow system exits?

hard

A. StandardError

B. Exception

C. RuntimeError

D. NoMethodError

Solution

1. Step 1: Understand exception classes for system exit

   Classes like SystemExit and Interrupt inherit directly from Exception, not StandardError.

2. Step 2: Choose rescue class to exclude system exits

   Rescuing StandardError catches most runtime errors but excludes system-exiting exceptions.

3. Step 3: Confirm other options

   Rescuing Exception catches everything including system exits, which is usually not desired.

4. Final Answer:

   StandardError -> Option A

5. Quick Check:

   Rescue StandardError to exclude system exits [OK]

Hint: Rescue StandardError to avoid catching system exits [OK]

Common Mistakes:

• Rescuing Exception catches system exits too
• Choosing RuntimeError misses some errors
• Confusing NoMethodError as base class