Lesson 03

Result error boundaries

Return Result from fallible boundaries so callers can choose retry, rejection, or user-facing error copy.

result
errors
boundaries

Good Code

src/review_loader.rs

use std::fs;
use std::path::Path;

pub fn load_review(path: &Path) -> Result<String, std::io::Error> {
    // File errors stay in the return type for the caller to classify.
    fs::read_to_string(path)
}

Bad Code

review_loader.rs

use std::fs;
use std::path::Path;

pub fn load_review(path: &Path) -> String {
    // unwrap turns a normal missing-file path into a process panic.
    fs::read_to_string(path).unwrap()
}

Review Notes

What to review

Good Code

The good version returns Result, leaving the caller in control of logging, retrying, returning 404, or surfacing validation copy.

Bad Code

The bad version uses unwrap at an I/O boundary. A missing file, permission error, or invalid path becomes a panic instead of a recoverable branch.

Takeaways

Rust boundary code should return typed errors instead of panicking on expected failure paths.