Custom exception classes in Ruby - Step-by-Step Execution

Concept Flow - Custom exception classes

Define custom exception class

↓

Raise custom exception

↓

Exception caught?

No→Program crashes

Yes↓

Handle exception

↓

Continue

This flow shows how a custom exception class is defined, raised, caught, and handled in Ruby.

Execution Sample

Ruby

class MyError < StandardError; end

def test_error
  raise MyError, "Oops!"
rescue MyError => e
  puts e.message
end

test_error

Defines a custom error, raises it, catches it, and prints the error message.

Execution Table

Step	Action	Evaluation	Result
1	Define class MyError < StandardError	Class created	MyError is ready to use
2	Call test_error method	Method starts	Execution enters test_error
3	Raise MyError with message 'Oops!'	Exception raised	MyError exception thrown
4	Rescue MyError exception	Exception caught	Variable e holds exception
5	puts e.message	Print message	Output: Oops!
6	Method ends	No more code	Return nil
7	Program ends	No errors	Normal exit

💡 Program ends normally after handling the custom exception.

Variable Tracker

Variable	Start	After Step 3	After Step 4	Final
e	nil	nil	Exception object (MyError)	Exception object (MyError)

Key Moments - 3 Insights

Why do we inherit from StandardError when creating a custom exception?

In Ruby, rescuing StandardError catches most common errors. By inheriting from StandardError, your custom exception works with rescue blocks as shown in step 4.

What happens if we raise the custom exception but do not rescue it?

If not rescued, the program crashes and shows the error message. In the execution_table, step 4 shows catching the exception; without it, the program would stop there.

How do we access the error message inside the rescue block?

The rescue block assigns the exception to variable e (step 4). We use e.message to get the message string, as shown in step 5.

Visual Quiz - 3 Questions

Look at the execution table, what is the value of variable e after step 3?

A nil

B String 'Oops!'

C Exception object (MyError)

D StandardError object

💡 Hint

Check variable_tracker after step 3 to see what e holds.

At which step does the program catch the custom exception?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the execution_table 'Action' column for 'Rescue MyError exception'.

If we remove the rescue block, what would happen at step 4?

A Exception is caught anyway

B Program crashes with error

C Nothing happens, program continues

D Error message prints automatically

💡 Hint

Refer to key_moments about what happens if exception is not rescued.

Concept Snapshot

Define a custom exception class by inheriting StandardError.
Raise it with raise MyError, 'message'.
Use rescue MyError => e to catch it.
Access message with e.message.
Without rescue, program crashes.
Custom exceptions help handle specific errors clearly.

Full Transcript

This example shows how to create a custom exception class in Ruby by inheriting from StandardError. The test_error method raises this custom exception with a message. The rescue block catches the exception and assigns it to variable e. Then, e.message prints the error message. The program continues normally after handling the exception. If the rescue block was missing, the program would crash when the exception is raised. This flow helps you handle errors in your code clearly and safely.

Practice

1. What is the main purpose of creating a custom exception class in Ruby?

easy

A. To define specific error types for clearer error handling

B. To speed up the program execution

C. To replace all built-in exceptions

D. To automatically fix errors in the code

Solution

1. Step 1: Understand the role of exceptions

   Exceptions represent errors or unexpected events in a program.

2. Step 2: Purpose of custom exceptions

   Custom exceptions let you create specific error types to handle different problems clearly.

3. Final Answer:

   To define specific error types for clearer error handling -> Option A

4. Quick Check:

   Custom exceptions = clearer error handling [OK]

Hint: Custom exceptions clarify error types for better handling [OK]

Common Mistakes:

• Thinking custom exceptions speed up code
• Believing they replace built-in exceptions
• Assuming they fix errors automatically

2. Which of the following is the correct way to define a custom exception class in Ruby?

easy

A. class MyError < StandardError; end

B. class MyError < Exception; end

C. def MyError; end

D. exception MyError inherits StandardError

Solution

1. Step 1: Check Ruby syntax for class inheritance

   In Ruby, custom exceptions inherit from StandardError for best practice.

2. Step 2: Identify correct class definition

   class MyError < StandardError; end correctly defines a class inheriting from StandardError using Ruby syntax.

3. Final Answer:

   class MyError < StandardError; end -> Option A

4. Quick Check:

   Custom exception syntax = class MyError < StandardError [OK]

Hint: Custom exceptions inherit StandardError with class syntax [OK]

Common Mistakes:

• Inheriting directly from Exception (not recommended)
• Using def instead of class
• Wrong inheritance syntax

3. What will be the output of this Ruby code?

class MyError < StandardError; end

begin
  raise MyError, "Something went wrong"
rescue MyError => e
  puts e.message
end

medium

A. MyError

B. StandardError

C. No output

D. Something went wrong

Solution

1. Step 1: Understand raise and rescue

   The code raises a MyError with message "Something went wrong" and rescues it as variable e.

2. Step 2: Output from exception message

   Inside rescue, puts e.message prints the error message string.

3. Final Answer:

   Something went wrong -> Option D

4. Quick Check:

   e.message prints error message string [OK]

Hint: e.message prints the error message string [OK]

Common Mistakes:

• Printing class name instead of message
• Expecting no output
• Confusing exception class with message

4. Identify the error in this Ruby code defining a custom exception:

class MyError
  def initialize(msg)
    super(msg)
  end
end

medium

A. Incorrect method name 'initialize'

B. Missing inheritance from StandardError

C. super should not be called in initialize

D. Class name should be lowercase

Solution

1. Step 1: Check class inheritance

   The class does not inherit from StandardError or any exception class, so it won't behave as an exception.

2. Step 2: Confirm other parts are correct

   Method name and super call are correct for passing message to parent class.

3. Final Answer:

   Missing inheritance from StandardError -> Option B

4. Quick Check:

   Custom exceptions must inherit StandardError [OK]

Hint: Always inherit StandardError for custom exceptions [OK]

Common Mistakes:

• Forgetting to inherit StandardError
• Thinking initialize method name is wrong
• Believing super call is unnecessary

5. You want to create a custom exception that stores an error code along with the message. Which code correctly implements this?

hard

A. class CodeError < StandardError
def initialize(msg)
@code = msg
end
end

B. class CodeError
def initialize(msg, code)
@code = code
super(msg)
end
end

C. class CodeError < StandardError
attr_reader :code
def initialize(msg, code)
super(msg)
@code = code
end
end

D. class CodeError < Exception
def initialize(code)
@code = code
end
end

Solution

1. Step 1: Check inheritance and attribute

   class CodeError < StandardError attr_reader :code def initialize(msg, code) super(msg) @code = code end end inherits from StandardError and defines attr_reader for code to access it.

2. Step 2: Verify initialize method

   It calls super(msg) to set the message and stores code in @code correctly.

3. Final Answer:

   class CodeError < StandardError with attr_reader and initialize(msg, code) -> Option C

4. Quick Check:

   Custom exception with extra data = class CodeError < StandardError attr_reader :code def initialize(msg, code) super(msg) @code = code end end [OK]

Hint: Use attr_reader and call super(msg) in initialize [OK]

Common Mistakes:

• Not inheriting from StandardError
• Calling super after instance variables
• Missing attr_reader for code