Result/Error Handling Pattern

The Result/Error Handling pattern in Rust is a fundamental approach to error management that makes error handling explicit and type-safe. While not strictly one of the Gang of Four design patterns, it's a crucial pattern in Rust that provides a robust alternative to exception-based error handling found in classical OOP languages like Java.

What is the Result Pattern?

The Result pattern uses Rust's Result<T, E> enum to represent either a successful value (Ok(T)) or an error (Err(E)). This forces developers to explicitly handle both success and failure cases, preventing runtime crashes from unhandled exceptions.

Comparison with Java

In Java, error handling typically uses exceptions:

// Java - Exception-based error handling
public class FileProcessor {
    public String readFile(String filename) throws IOException {
        // May throw IOException
        return Files.readString(Paths.get(filename));
    }

    public void processFile(String filename) {
        try {
            String content = readFile(filename);
            System.out.println("Content: " + content);
        } catch (IOException e) {
            System.err.println("Error reading file: " + e.getMessage());
        }
    }
}

Rust Implementation

use std::fs;
use std::io;
use std::fmt;

// Custom error type for our application
#[derive(Debug)]
enum FileProcessError {
    IoError(io::Error),
    InvalidContent(String),
    EmptyFile,
}

impl fmt::Display for FileProcessError {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        match self {
            FileProcessError::IoError(err) => write!(f, "IO error: {}", err),
            FileProcessError::InvalidContent(msg) => write!(f, "Invalid content: {}", msg),
            FileProcessError::EmptyFile => write!(f, "File is empty"),
        }
    }
}

impl From<io::Error> for FileProcessError {
    fn from(error: io::Error) -> Self {
        FileProcessError::IoError(error)
    }
}

struct FileProcessor;

impl FileProcessor {
    // Returns Result<T, E> instead of throwing exceptions
    fn read_file(filename: &str) -> Result<String, FileProcessError> {
        let content = fs::read_to_string(filename)?; // ? operator for error propagation

        if content.is_empty() {
            return Err(FileProcessError::EmptyFile);
        }

        Ok(content)
    }

    // Validates file content
    fn validate_content(content: &str) -> Result<&str, FileProcessError> {
        if content.len() < 10 {
            return Err(FileProcessError::InvalidContent(
                "Content too short".to_string()
            ));
        }
        Ok(content)
    }

    // Chains multiple Result operations
    fn process_file(filename: &str) -> Result<String, FileProcessError> {
        let content = Self::read_file(filename)?;
        let validated_content = Self::validate_content(&content)?;

        // Process the content (just uppercase for this example)
        Ok(validated_content.to_uppercase())
    }
}

fn main() {
    let filenames = vec!["example.txt", "nonexistent.txt", "empty.txt"];

    for filename in filenames {
        // Pattern matching for error handling
        match FileProcessor::process_file(filename) {
            Ok(processed_content) => {
                println!("✅ Successfully processed {}: {}", filename,
                        &processed_content[..50.min(processed_content.len())]);
            }
            Err(error) => {
                println!("❌ Error processing {}: {}", filename, error);
            }
        }
    }

    // Alternative error handling approaches
    demonstrate_error_handling_patterns();
}

fn demonstrate_error_handling_patterns() {
    println!("\n--- Different Error Handling Patterns ---");

    // 1. Using unwrap_or for default values
    let result1 = FileProcessor::read_file("nonexistent.txt")
        .unwrap_or_else(|_| "Default content".to_string());
    println!("With default: {}", result1);

    // 2. Using map and map_err for transformations
    let result2 = FileProcessor::read_file("example.txt")
        .map(|content| content.len())
        .map_err(|err| format!("Transformed error: {}", err));

    match result2 {
        Ok(length) => println!("Content length: {}", length),
        Err(err) => println!("Error: {}", err),
    }

    // 3. Chaining operations with and_then
    let result3 = FileProcessor::read_file("example.txt")
        .and_then(|content| {
            FileProcessor::validate_content(&content)?;
            Ok(content)
        })
        .map(|content| format!("Processed: {}", content.to_uppercase()));

    match result3 {
        Ok(processed) => println!("{}", processed),
        Err(err) => println!("Chain error: {}", err),
    }
}

// Demonstrating the ? operator sugar
fn complex_operation(filename: &str) -> Result<usize, FileProcessError> {
    // Each ? will return early if there's an error
    let content = FileProcessor::read_file(filename)?;
    let validated = FileProcessor::validate_content(&content)?;
    let processed = validated.to_uppercase();

    Ok(processed.len())
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_successful_processing() {
        // Create a temporary file for testing
        std::fs::write("test_file.txt", "This is a test file with enough content").unwrap();

        let result = FileProcessor::process_file("test_file.txt");
        assert!(result.is_ok());

        // Cleanup
        std::fs::remove_file("test_file.txt").ok();
    }

    #[test]
    fn test_empty_file_error() {
        // Create an empty file
        std::fs::write("empty_test.txt", "").unwrap();

        let result = FileProcessor::read_file("empty_test.txt");
        assert!(matches!(result, Err(FileProcessError::EmptyFile)));

        // Cleanup
        std::fs::remove_file("empty_test.txt").ok();
    }
}

Key Advantages of Rust's Result Pattern

**1. Explicit Error Handling: Unlike Java's checked exceptions that can be ignored or forgotten, Rust's Result type forces you to handle errors explicitly.

**2. No Hidden Control Flow: Unlike exceptions that can unwind the stack unpredictably, Results make error propagation explicit and traceable.

**3. Composability: Results can be chained using methods like map, and_then, unwrap_or, making error handling both functional and readable.

**4. Zero-Cost Abstractions: The ? operator provides clean syntax without runtime overhead.

**5. Type Safety: The compiler ensures you handle all possible error cases, preventing runtime crashes from unhandled exceptions.

Comparison Summary

The Result pattern exemplifies Rust's philosophy of "making errors impossible to ignore" while providing ergonomic tools for error handling that are both safer and more performant than traditional exception-based approaches.

Core Rust concepts introduced

Building on the previous patterns, the Error Handling pattern introduces several new concepts:

1. Enums with Data and Pattern Matching

#![allow(unused)]
fn main() {
#[derive(Debug)]
enum FileProcessError {
    IoError(io::Error),        // Variant holding another error type
    InvalidContent(String),     // Variant holding a String
    EmptyFile,                 // Unit variant (no data)
}

match FileProcessor::process_file(filename) {
    Ok(processed_content) => { /* handle success */ }
    Err(error) => { /* handle error */ }
}
}

• Enum variants with data: Each variant can hold different types of data
• Exhaustive pattern matching: match requires handling all possible cases
• Destructuring in patterns: Extract data from enum variants
• Sum types: Enums represent "one of" several possible values

2. The ? Operator and Error Propagation

#![allow(unused)]
fn main() {
let content = fs::read_to_string(filename)?;  // Early return on error
let validated = Self::validate_content(&content)?;
}

• Early return shorthand: ? returns immediately if Result is Err
• Automatic conversion: Uses From trait to convert between error types
• Syntactic sugar: Eliminates verbose match statements for error propagation
• Function signature requirement: Function must return Result to use ?

3. From Trait and Automatic Error Conversion

#![allow(unused)]
fn main() {
impl From<io::Error> for FileProcessError {
    fn from(error: io::Error) -> Self {
        FileProcessError::IoError(error)
    }
}
}

• Automatic conversions: ? operator uses From implementations
• Error type unification: Convert different error types to a common error type
• Composable error handling: Build error hierarchies without manual conversion
• Zero-cost conversion: From implementations are inlined

4. Result Combinators and Functional Error Handling

#![allow(unused)]
fn main() {
let result = FileProcessor::read_file("file.txt")
    .map(|content| content.len())                    // Transform success value
    .map_err(|err| format!("Error: {}", err))       // Transform error value
    .and_then(|len| if len > 0 { Ok(len) } else { Err("Empty".to_string()) });
}

• Functional composition: Chain operations that might fail
• map: Transform the success value, leave errors unchanged
• map_err: Transform the error value, leave success unchanged
• and_then: Chain operations that also return Result
• Monadic interface: Results form a monad for error handling

5. Error Display and Debug Traits

#![allow(unused)]
fn main() {
impl fmt::Display for FileProcessError {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        match self {
            FileProcessError::IoError(err) => write!(f, "IO error: {}", err),
            FileProcessError::InvalidContent(msg) => write!(f, "Invalid content: {}", msg),
            FileProcessError::EmptyFile => write!(f, "File is empty"),
        }
    }
}
}

• Display trait: Defines user-facing error messages
• Debug trait: Defines debugging representation (via #[derive(Debug)])
• Error trait: Standard trait for error types (not shown but commonly used)
• Hierarchical error information: Errors can wrap and display other errors

6. Unit Structs for Namespacing

#![allow(unused)]
fn main() {
struct FileProcessor;  // Unit struct with no fields

impl FileProcessor {
    fn read_file(filename: &str) -> Result<String, FileProcessError> { /* ... */ }
}
}

• Unit structs: Types with no data, used for namespacing
• Zero-size types: No runtime memory cost
• Associated functions: Group related functions under a type
• No inheritance: Use modules and types for organization instead

7. Advanced Error Handling Patterns

#![allow(unused)]
fn main() {
// Chaining with and_then for complex validation
let result = FileProcessor::read_file("file.txt")
    .and_then(|content| {
        FileProcessor::validate_content(&content)?;
        Ok(content)
    })
    .map(|content| content.to_uppercase());
}

• Error short-circuiting: First error stops the entire chain
• Nested error handling: Use ? inside closures passed to and_then
• Transformation pipelines: Build complex processing pipelines
• Fail-fast behavior: Errors propagate immediately without executing later steps

8. Testing Error Conditions

#![allow(unused)]
fn main() {
#[test]
fn test_empty_file_error() {
    let result = FileProcessor::read_file("empty_test.txt");
    assert!(matches!(result, Err(FileProcessError::EmptyFile)));
}
}

• matches! macro: Pattern matching in assertions
• Testing error paths: Verify that errors occur under expected conditions
• Specific error checking: Test for exact error variants, not just failure

9. Errors as Values Philosophy

This pattern demonstrates Rust's fundamental approach to error handling:

• No hidden control flow: Errors don't "jump" through the call stack
• Explicit in types: Function signatures show whether they can fail
• Composable: Errors can be transformed, chained, and combined
• Performance: No stack unwinding or exception handling overhead

These concepts show how Rust's type system makes error handling both safer and more explicit than exception-based systems, while providing powerful tools for composing error-handling logic.