Custom error types in Rust - Step-by-Step Execution

Concept Flow - Custom error types

Define struct or enum for error

↓

Implement std::fmt::Display

↓

Implement std::error::Error

↓

Use error type in functions

↓

Return Result<T, CustomError>

↓

Handle error with match or ? operator

↓

End

Create a custom error type by defining a struct or enum, implement Display and Error traits, then use it in functions returning Result to handle errors clearly.

Execution Sample

Rust

use std::fmt;

#[derive(Debug)]
enum MyError {
    NotFound,
    InvalidInput(String),
}

impl fmt::Display for MyError {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        match self {
            MyError::NotFound => write!(f, "Item not found"),
            MyError::InvalidInput(msg) => write!(f, "Invalid input: {}", msg),
        }
    }
}

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

fn find_item(id: i32) -> Result<String, MyError> {
    if id == 0 {
        Err(MyError::NotFound)
    } else if id < 0 {
        Err(MyError::InvalidInput("negative id".to_string()))
    } else {
        Ok("Item found".to_string())
    }
}

fn main() {
    match find_item(-1) {
        Ok(item) => println!("{}", item),
        Err(e) => println!("Error: {}", e),
    }
}

Defines a custom error enum with two variants, implements Display and Error traits, then uses it in a function returning Result to handle errors.

Execution Table

Step	Code Line	Action	Variable/State	Output/Result
1	Define enum MyError	Create custom error type with variants NotFound and InvalidInput	MyError enum defined
2	Implement Display for MyError	Define how error messages are shown	Display trait implemented
3	Implement Error for MyError	Mark MyError as an error type	Error trait implemented
4	Call find_item(-1)	Start function with id = -1	id = -1
5	Check if id == 0	Condition false	id = -1
6	Check if id < 0	Condition true	id = -1	Return Err(MyError::InvalidInput("negative id"))
7	Match in main on Result	Err branch taken	e = InvalidInput("negative id")	Print: Error: Invalid input: negative id
8	Program ends	No more code

💡 Function returns Err variant because id < 0 condition is true, main prints error message and program ends.

Variable Tracker

Variable	Start	After Step 4	After Step 6	Final
id	undefined	-1	-1	-1
Result from find_item	undefined	pending	Err(MyError::InvalidInput("negative id"))	Err(MyError::InvalidInput("negative id"))
e (error in main)	undefined	undefined	InvalidInput("negative id")	InvalidInput("negative id")

Key Moments - 3 Insights

Why do we implement the Display trait for the custom error?

Implementing Display lets us define the error message shown when printing the error, as seen in execution_table step 7 where the error message is printed.

What happens if the function returns Err? How is it handled?

When find_item returns Err (step 6), main matches on the Result and takes the Err branch (step 7), printing the error message instead of panicking.

Why use an enum for custom errors instead of just a struct?

An enum lets us represent different kinds of errors in one type, like NotFound and InvalidInput, making error handling clearer and more flexible (step 1).

Visual Quiz - 3 Questions

Look at the execution_table at step 6. What error variant is returned by find_item(-1)?

A MyError::InvalidInput("negative id")

B MyError::NotFound

C Ok("Item found")

D None

💡 Hint

Check the 'Output/Result' column at step 6 in the execution_table.

At which step does the main function print the error message?

A Step 5

B Step 7

C Step 4

D Step 8

💡 Hint

Look for the step where 'Print: Error: Invalid input: negative id' appears in the execution_table.

If find_item was called with id = 0, what would be the returned error variant?

A Ok("Item found")

B MyError::InvalidInput("negative id")

C MyError::NotFound

D No error

💡 Hint

Refer to the condition checks in the code and execution_table steps 5 and 6.

Concept Snapshot

Define a custom error type using enum or struct.
Implement fmt::Display to show error messages.
Implement std::error::Error to mark it as an error.
Use Result<T, CustomError> in functions.
Handle errors with match or ? operator.

Full Transcript

This example shows how to create custom error types in Rust. We define an enum MyError with variants NotFound and InvalidInput. We implement the Display trait to control how error messages appear when printed. We also implement the Error trait to mark MyError as a proper error type. The function find_item returns a Result with our custom error. It returns Err with NotFound if id is zero, Err with InvalidInput if id is negative, or Ok if id is positive. In main, we call find_item with -1, which triggers the InvalidInput error. We match on the Result and print the error message. This step-by-step trace shows how variables change and how errors flow through the program.

Practice

1. What is the main purpose of creating a custom error type in Rust?

easy

A. To automatically fix bugs in the code.

B. To make the program run faster by avoiding errors.

C. To replace the need for using Result types.

D. To describe specific problems in your program with clear error messages.

Solution

1. Step 1: Understand the role of custom errors

   Custom error types help programmers describe specific problems clearly in their code.

2. Step 2: Compare with other options

   Custom errors do not speed up code, fix bugs automatically, or replace Result types; they provide clear error descriptions.

3. Final Answer:

   To describe specific problems in your program with clear error messages. -> Option D

4. Quick Check:

   Custom error purpose = clear problem description [OK]

Hint: Custom errors explain problems clearly, not fix or speed up code [OK]

Common Mistakes:

• Thinking custom errors fix bugs automatically
• Confusing custom errors with performance improvements
• Believing custom errors replace Result types

2. Which of the following is the correct way to start defining a custom error enum in Rust?

easy

A. enum MyError { Io(std::io::Error), Parse(std::num::ParseIntError) }

B. struct MyError { message: String }

C. fn MyError() -> Error {}

D. class MyError { error: String }

Solution

1. Step 1: Identify Rust enum syntax

   Rust uses enum to define custom error types with variants, like Io(std::io::Error).

2. Step 2: Check other options

   struct is for data structures, fn is for functions, and class is not Rust syntax.

3. Final Answer:

   enum MyError { Io(std::io::Error), Parse(std::num::ParseIntError) } -> Option A

4. Quick Check:

   Custom error enum = enum with variants [OK]

Hint: Custom errors use enum with variants, not struct or class [OK]

Common Mistakes:

• Using struct instead of enum for error variants
• Trying to define errors as functions
• Using class keyword which is invalid in Rust

3. What will be the output of this Rust code snippet?

use std::fmt;

#[derive(Debug)]
enum MyError {
    NotFound,
    PermissionDenied,
}

impl fmt::Display for MyError {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        match self {
            MyError::NotFound => write!(f, "Item not found"),
            MyError::PermissionDenied => write!(f, "Permission denied"),
        }
    }
}

fn main() {
    let err = MyError::NotFound;
    println!("Error: {}", err);
}

medium

A. Error: NotFound

B. Error: Item not found

C. Error: Permission denied

D. Compilation error due to missing trait

Solution

1. Step 1: Understand Display implementation

   The fmt method matches MyError::NotFound and writes "Item not found" to the formatter.

2. Step 2: Check main output

   Printing err with {} uses Display, so output is "Error: Item not found".

3. Final Answer:

   Error: Item not found -> Option B

4. Quick Check:

   Display prints custom message = "Item not found" [OK]

Hint: Display trait controls {} output, matching variant message shown [OK]

Common Mistakes:

• Expecting Debug output instead of Display
• Confusing variant name with message
• Assuming compilation error without Display trait

4. Identify the error in this custom error implementation:

enum MyError {
    Io(std::io::Error),
}

impl std::fmt::Display for MyError {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        write!(f, "{}", self.0)
    }
}

medium

A. Cannot access self.0 because enum variant is not destructured.

B. Missing implementation of Debug trait.

C. Display trait cannot be implemented for enums.

D. write! macro requires a string literal, not a variable.

Solution

1. Step 1: Check how self.0 is accessed

   In an enum, you cannot directly access self.0 without matching or destructuring the variant.

2. Step 2: Understand correct pattern

   You must match self to get the inner std::io::Error value before using it in write!.

3. Final Answer:

   Cannot access self.0 because enum variant is not destructured. -> Option A

4. Quick Check:

   Enum variant fields need matching before access [OK]

Hint: Match enum variants before accessing inner fields [OK]

Common Mistakes:

• Trying to access enum fields directly without match
• Thinking Display can't be implemented for enums
• Assuming Debug trait is mandatory for Display

5. You want to create a custom error type that can hold either an IO error or a parsing error, and provide user-friendly messages. Which of these is the best complete approach?

hard

A. Create separate error structs for IO and parse errors without enums, and use panic! for messages.

B. Use a struct with two optional fields for IO and parse errors, and implement Display only.

C. Define an enum with variants for each error type, implement Display with match arms for messages, and implement std::error::Error.

D. Use a type alias for Result with String errors and skip custom error types.

Solution

1. Step 1: Choose enum for multiple error types

   An enum cleanly groups different error variants like IO and parse errors.

2. Step 2: Implement Display and std::error::Error traits

   Display provides friendly messages; implementing std::error::Error integrates with Rust error handling.

3. Final Answer:

   Define an enum with variants for each error type, implement Display with match arms for messages, and implement std::error::Error. -> Option C

4. Quick Check:

   Enum + Display + Error trait = best custom error pattern [OK]

Hint: Use enum + Display + Error trait for best custom error design [OK]

Common Mistakes:

• Using struct with optional fields causing confusion
• Skipping std::error::Error trait implementation
• Using panic! instead of proper error handling