Error-Aware Pattern Matching

In this lesson, you will learn how to combine match guard clauses with error variants to perform precise, context-aware validation during error recovery.

Beyond Simple Matching

When dealing with domain-specific error enums, a simple match often isn't enough. Sometimes, you need to decide whether to recover from an error based on the state of the error payload or the external environment. This is where match guards become indispensable.

By combining match patterns with if conditions, you can create fine-grained branching logic that treats specific error values differently depending on whether they meet your business rules.

Implementation Pattern

Imagine a system where a FileError might be transient or permanent. We want to retry only if the error indicates a capacity issue, but only if we have remaining retries.

enum FileError {
    AccessDenied,
    DiskFull(u64), // bytes missing
    Unknown,
}

fn handle_error(err: FileError, retries: usize) -> Result<(), FileError> {
    match err {
        // Only retry if we have space left and the error is DiskFull
        FileError::DiskFull(bytes) if bytes < 1024 && retries > 0 => {
            println!("Small disk error, attempting retry...");
            Ok(())
        }
        // Guard failed or other error type; propagate the error
        e => Err(e),
    }
}

Why This Matters

Without guard clauses, you would be forced to write nested if statements inside your error handler, which muddies the logic and obscures the "happy path" of your code. Match guards keep your error handling declarative. By inspecting the variant and the metadata (like the bytes count or your retry counter) simultaneously, you consolidate your branching logic into a single, readable block. This is especially powerful when integrating library errors where you might only want to recover from a specific sub-variant if a specific condition is met.

This pattern ensures that your error handling remains as strict as your domain requirements, preventing unnecessary retries or incorrect recoveries that could lead to unstable application states.

Key Takeaway: Use match guards to filter error variants based on runtime state, allowing you to selectively recover from errors without cluttering your code with nested conditional logic.