Bird
Raised Fist0
Rubyprogramming~10 mins

Custom exception classes in Ruby - Interactive Code Practice

Choose your learning style10 modes available
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to define a custom exception class named MyError.

Ruby
class MyError < [1]
end
Drag options to blanks, or click blank then click option'
AException
BStandardError
CRuntimeError
DError
Attempts:
3 left
💡 Hint
Common Mistakes
Inheriting directly from Exception can cause unexpected behavior.
Using a non-existent class like Error will cause a NameError.
2fill in blank
medium

Complete the code to raise the custom exception MyError with a message.

Ruby
raise [1], "Something went wrong"
Drag options to blanks, or click blank then click option'
AMyError
BMyError.new
CStandardError
DException
Attempts:
3 left
💡 Hint
Common Mistakes
Using MyError.new raises an instance but is not the common pattern.
Raising Exception or StandardError raises built-in errors, not the custom one.
3fill in blank
hard

Fix the error in the code to rescue the custom exception MyError.

Ruby
begin
  # some code
rescue [1] => e
  puts e.message
end
Drag options to blanks, or click blank then click option'
ARuntimeError
BStandardError
CException
DMyError
Attempts:
3 left
💡 Hint
Common Mistakes
Rescuing Exception or StandardError catches too many errors.
Using RuntimeError does not catch MyError unless it inherits from it.
4fill in blank
hard

Fill both blanks to define a custom exception with a message method.

Ruby
class MyError < [1]
  def [2]
    "Custom error occurred"
  end
end
Drag options to blanks, or click blank then click option'
AStandardError
Bmessage
CException
Dinitialize
Attempts:
3 left
💡 Hint
Common Mistakes
Defining initialize instead of message changes how the error is created.
Inheriting from Exception is less common and can cause issues.
5fill in blank
hard

Fill all three blanks to raise and rescue a custom exception with a message.

Ruby
begin
  raise [1], "Oops!"
rescue [2] => e
  puts e.[3]
end
Drag options to blanks, or click blank then click option'
AMyError
Cmessage
DStandardError
Attempts:
3 left
💡 Hint
Common Mistakes
Raising and rescuing different exception classes causes errors.
Using e.to_s instead of e.message changes output format.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard