Error Handling & Exceptions

Topics Covered in This Ruby on Rails Tutorial:

Handling Errors, Different Types of Errors, the Raise Method

Exercise Overview

In this exercise, we'll explore Ruby's sophisticated error handling and exception management system. Even the most carefully crafted applications encounter unexpected conditions—network timeouts, invalid user input, missing files, or corrupted data. Rather than letting these scenarios crash your application and frustrate users, Ruby provides powerful tools to anticipate, catch, and gracefully handle errors. Mastering these techniques separates professional developers from beginners and is essential for building production-ready applications that maintain reliability under real-world conditions.

Handling Errors

The foundation of robust application design lies in preventing minor issues from cascading into major failures. Ruby's exception handling system gives you precise control over how your application responds when things go wrong, allowing you to provide meaningful feedback to users while maintaining system stability.

1. If Interactive Ruby isn't running, open Terminal and launch IRB with the irb command.

2. In Terminal, type:

   puts doggerel

   Terminal returns an error: NameError (undefined local variable or method 'doggerel' for main:Object) because this variable doesn't exist. In a production web application, this type of error could display an ugly error page to users instead of the content they expect. While a missing variable might seem trivial, such errors can break entire page layouts, interrupt user workflows, and damage your application's credibility. Professional applications handle these gracefully.

3. Ruby provides elegant control structures for this exact scenario. Implement the following begin…end block:

   begin
         puts doggerel
      rescue
      puts "No doggerel today!"
      end

   The rescue clause specifies exactly what happens when an error occurs, giving you complete control over the user experience. Instead of cryptic error messages, users see your carefully crafted response. In production applications, you might display user-friendly messages, redirect to alternative content, log detailed error information for debugging, or silently fall back to default values. This pattern is fundamental to professional Ruby development and appears throughout Rails applications, from controller actions to background job processing.

   For even more precise control, you can target specific error types with rescue. Notice that our initial attempt produced a NameError—we can handle different exceptions differently based on their type and severity.

4. Let's examine another common error type. Execute the following:

   2 + '2'

   Terminal returns a TypeError—Ruby cannot perform mathematical operations between incompatible data types. This type of error frequently occurs when processing user input, API responses, or data imports where you can't guarantee data types. Understanding and handling TypeErrors is crucial for applications that process dynamic content.

5. Now we'll create a sophisticated error handling method that demonstrates how professional applications manage different error types with tailored responses. Create this method:

   def should_break
      begin
         yield

   This method accepts a block of potentially problematic code via yield, allowing us to test different error scenarios in a controlled environment. This pattern mirrors real-world scenarios where you might process user-submitted code, evaluate dynamic expressions, or execute operations with uncertain outcomes.

6. Specify the response for NameError exceptions:

   rescue NameError
   puts "No such variable exists."

7. Define handling for TypeError exceptions:

   rescue TypeError
      puts "Mismatch of variable types."
      end

   This multi-catch approach allows your applications to provide context-specific error messages, helping users understand what went wrong and potentially how to fix it. In production systems, different error types might trigger different logging levels, notification systems, or recovery procedures.

8. Test the NameError handling:

   should_break { puts doggerel }

   Output: No such variable exists.

9. Test the TypeError handling:

   should_break { 2 + '2' }

   Output: Mismatch of variable types.

With solid error catching established, let's explore how to proactively raise exceptions when your application detects problematic conditions that require immediate attention.

Raising Errors

While catching external errors is essential, professional applications also need to enforce their own business rules and constraints. The raise method allows you to throw exceptions when your code detects conditions that shouldn't proceed—invalid parameters, violated business logic, or security concerns. This proactive approach prevents subtle bugs from propagating through your system and makes debugging significantly easier.

1. Let's build a User class that enforces naming constraints to avoid potential trademark issues. Initialize the class with validation:

   class User
      attr_accessor :name
      def initialize(name)

2. Implement proactive validation using Ruby's built-in ArgumentError:

   raise ArgumentError, "Name is copyrighted" if name == 'Mickey Mouse'
      @name = name
      end

   The raise method immediately halts execution and throws the specified exception unless rescue code handles it appropriately. This pattern is invaluable for enforcing business rules, validating input parameters, and maintaining data integrity. Professional applications use raise extensively to fail fast when encountering invalid states, preventing corrupted data from spreading through the system.

3. Create a valid user instance:

   u = User.new("Jamie")

4. Verify the name assignment:

   u.name

   Returns: "Jamie"

5. Test the validation by attempting to create a restricted user:

   u = User.new("Mickey Mouse")

   Returns: ArgumentError: Name is copyrighted

   We chose ArgumentError because the name parameter represents invalid input—the exception type clearly communicates what went wrong. In production applications, choosing appropriate exception types helps debugging and allows calling code to handle different error scenarios appropriately.

6. Confirm that the invalid assignment was prevented:

   u.name

   Still returns: "Jamie" because execution stopped before the assignment occurred, maintaining data integrity.

7. For application-specific errors, create custom exception classes by inheriting from RuntimeError:

   class CopyrightError < RuntimeError
      end

   Custom exception classes make your code more expressive and allow calling code to handle domain-specific errors differently from generic system errors. This approach is standard in professional Rails applications, where you might have exceptions like PaymentProcessingError, InsufficientInventoryError, or AccessDeniedError.

8. Demonstrate your custom exception:

   raise CopyrightError, "Name is copyrighted"

   Congratulations! You've created and raised a custom CopyrightError, demonstrating professional exception handling practices.

9. Close Terminal and click Terminate if prompted.