Ruby exception Handling Pitfall: Understanding Rescue Clause Hierarchy

Context

Let's consider the following code, defining basic classes and one custom error:

class CustomError < StandardError; end



class Parent

  def raise_custom_error

    raise CustomError

  rescue StandardError

    puts "StandardError rescued"

  end

end



class Child < Parent

  def call

    raise_custom_error

  rescue CustomError

    puts "CustomError rescued"

  end

end

Now, let's examine the following method call::

Child.new.call

To summarize, this code does the following:

• Defines a CustomError class that inherits from StandardError
  


• Creates a Child class with a #call method that invokes raise_custom_error from its parent class Parent
  


• Implements exception handling in both Child#call and Parent#raise_custom_error
  

Given this setup, we might expect the exception handling mechanism in Child#call to be triggered, as it appears to be the most specific. However, the actual output of the call is:

StandardError rescued

Surprisingly, we end up executing the more generic error handling defined in Parent#raise_custom_error.

How Rescuing Works

When Ruby encounters a raise statement, it looks up the call stack for matching rescue clauses. It checks whether the raised exception is a subclass of any exception specified in the rescue clause.

Explanation of the behaviour

The output "StandardError rescued" occurs because:

• When Parent#raise_custom_error raises CustomError, Ruby looks for matching rescue clauses in the method where the exception was raised


• It finds the rescue StandardError clause in Parent#raise_custom_error
  


• Since CustomError inherits from StandardError, this rescue clause matches and handles the exception


• By the time execution returns to Child#call, the exception has already been handled, so the rescue CustomError clause in Child#call never gets a chance to execute

Conclusion

Error-rescuing blocks cannot be written completely agnostically of the current class hierarchy. The order and specificity of rescue clauses matters due to exception inheritance.

When dealing with exceptions raised in parent classes, the rescue block in the parent class may catch exceptions before they reach the child class.

To avoid such scenarios, we can apply a principle related to exception hierarchy, which is closely tied to the Liskov Substitution Principle (LSP). The LSP states that subtypes should be substitutable for their base types, meaning that any code using a parent class should be able to work with a child class without knowing the difference.

In the context of exception handling specifically:

• More general exceptions should be caught at lower levels in the call stack or inheritance hierarchy.


• More specific exceptions should be caught closer to where they are raised.