Rust’s error handling capabilities go way beyond just Result and Option. While those are great building blocks, experienced Rustaceans know there’s a whole world of advanced techniques to level up your error game.

Let’s dive into custom error types - they’re a game changer when it comes to creating robust, maintainable code. I remember the first time I grokked this concept, it was like a light bulb went off. Suddenly my error messages were way more informative and debugging became a breeze.

The basic idea is to define your own error type that encapsulates all the possible failure modes of your program or library. This gives you fine-grained control over error reporting and handling.

Here’s a simple example to get us started:

#[derive(Debug)]
enum MyError {
    IoError(std::io::Error),
    ParseError(std::num::ParseIntError),
    CustomError(String),
}

impl std::error::Error for MyError {}

impl std::fmt::Display for MyError {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        match self {
            MyError::IoError(e) => write!(f, "IO error: {}", e),
            MyError::ParseError(e) => write!(f, "Parse error: {}", e),
            MyError::CustomError(s) => write!(f, "Custom error: {}", s),
        }
    }
}

This enum covers three types of errors we might encounter: IO errors, parsing errors, and our own custom errors. By implementing the std::error::Error trait, we’re saying “hey, this is a proper error type”. The Display implementation lets us control how the error is formatted when we print it.

But wait, there’s more! We can make our lives even easier by implementing From for our error type:

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

impl From<std::num::ParseIntError> for MyError {
    fn from(error: std::num::ParseIntError) -> Self {
        MyError::ParseError(error)
    }
}

Now we can use the ? operator with functions that return these error types, and they’ll automatically be converted to our MyError type. It’s like magic, but better because it’s type-safe!

Let’s put it all together in a real-world scenario. Say we’re writing a function that reads a number from a file and doubles it:

use std::fs::File;
use std::io::Read;

fn double_number_from_file(filename: &str) -> Result<i32, MyError> {
    let mut file = File::open(filename)?;
    let mut contents = String::new();
    file.read_to_string(&mut contents)?;
    let number: i32 = contents.trim().parse()?;
    Ok(number * 2)
}

Look at how clean that is! The ? operator is doing all the heavy lifting of error conversion for us. If any step fails, we’ll get a MyError with the specific details of what went wrong.

But we can take this even further. What if we want to add some context to our errors? Enter the anyhow crate. It’s like error handling on steroids.

With anyhow, we can wrap our errors with additional context:

use anyhow::{Context, Result};

fn double_number_from_file(filename: &str) -> Result<i32> {
    let mut file = File::open(filename)
        .with_context(|| format!("Failed to open file '{}'", filename))?;
    let mut contents = String::new();
    file.read_to_string(&mut contents)
        .context("Failed to read file contents")?;
    let number: i32 = contents
        .trim()
        .parse()
        .context("Failed to parse number from file")?;
    Ok(number * 2)
}

Now our errors will have rich, contextual information that makes debugging a breeze. Trust me, your future self will thank you for this!

But what about when we’re building libraries? That’s where thiserror comes in handy. It’s like a Swiss Army knife for creating custom error types.

Here’s how we could rewrite our MyError using thiserror:

use thiserror::Error;

#[derive(Error, Debug)]
enum MyError {
    #[error("IO error: {0}")]
    IoError(#[from] std::io::Error),
    #[error("Parse error: {0}")]
    ParseError(#[from] std::num::ParseIntError),
    #[error("Custom error: {0}")]
    CustomError(String),
}

Thiserror automatically implements Display and std::error::Error for us, as well as the From conversions. It’s a huge time-saver!

Now, let’s talk about a pattern I’ve found super useful: the fallible constructor. Sometimes, creating an object can fail, and we want to represent that in our types. Here’s an example:

struct Person {
    name: String,
    age: u8,
}

impl Person {
    fn new(name: String, age: u8) -> Result<Self, String> {
        if name.is_empty() {
            return Err("Name cannot be empty".to_string());
        }
        if age > 150 {
            return Err("Age seems unrealistic".to_string());
        }
        Ok(Person { name, age })
    }
}

This way, we can’t create invalid Person objects. It’s a great way to enforce invariants and make illegal states unrepresentable.

Another advanced technique is using the try_trait feature to define custom try operations. This lets you use the ? operator with types other than Result and Option. It’s still experimental, but it’s super cool:

#![feature(try_trait)]
use std::ops::Try;

struct MaybeString(Option<String>);

impl Try for MaybeString {
    type Ok = String;
    type Error = ();

    fn into_result(self) -> Result<Self::Ok, Self::Error> {
        self.0.ok_or(())
    }

    fn from_error(_: Self::Error) -> Self {
        MaybeString(None)
    }

    fn from_ok(v: Self::Ok) -> Self {
        MaybeString(Some(v))
    }
}

fn process_string(s: MaybeString) -> MaybeString {
    let string = s?;
    MaybeString(Some(string.to_uppercase()))
}

This opens up a whole new world of possibilities for custom control flow!

Lastly, let’s talk about backtraces. When an error occurs, it’s often super helpful to know the exact sequence of function calls that led to the error. Rust’s std::backtrace::Backtrace gives us this power:

use std::backtrace::Backtrace;

#[derive(Debug)]
struct MyError {
    message: String,
    backtrace: Backtrace,
}

impl MyError {
    fn new(message: &str) -> Self {
        MyError {
            message: message.to_string(),
            backtrace: Backtrace::capture(),
        }
    }
}

fn main() {
    if let Err(e) = might_fail() {
        println!("Error: {}", e.message);
        println!("Backtrace:\n{}", e.backtrace);
    }
}

This can be a lifesaver when debugging complex systems.

Error handling in Rust is a deep topic, and we’ve only scratched the surface here. But these advanced techniques can really level up your Rust code. They’ve certainly made my life easier!

Remember, good error handling isn’t just about catching failures - it’s about providing meaningful, actionable information when things go wrong. It’s about making your code more robust, more maintainable, and ultimately, more reliable.

So go forth and conquer those errors! Your future self (and your users) will thank you.