Day 4 is upon us! (and some thoughts about error handing)

[CarolineMorton]

🎅 Day 4 - Let's Talk About Error Handling! 🎄

I've been reviewing some of the solutions from the previous days, and I wanted to take a moment to discuss something that can really improve your Rust code: proper error handling! While unwrap(), expect(), and panic! are tempting (especially during coding challenges), this is a good opportunity to practice using a more robust approach - Result.

Why Result over unwrap/panic?

When we use unwrap() or panic!, we're essentially saying "crash the program if something goes wrong." While this might be fine for quick scripts, it's not ideal for:

• Understanding what actually went wrong. It just crashes!
• Handling errors gracefully - if you don't want it to crash, for example, on a server
• Writing maintainable code
• Testing error conditions

Here's a quick example of a common pattern I've seen, with a change to using Result.

// Instead of this:
let file_content = read_to_string("input.txt").expect("File read failed!");
let numbers: Vec<u32> = content
    .lines()
    .map(|x| x.parse().unwrap())
    .collect();

// Consider this:
fn parse_input(path: &str) -> Result<Vec<u32>, Box<dyn Error>> {
    let content = read_to_string(path)?;
    let numbers = content
        .lines()
        .map(|line| line.parse())
        .collect::<Result<_, _>>()?;
    Ok(numbers)
}

Custom Error Types

For bonus points, consider defining your own error types. This makes your code more expressive, and customisable to the problem you are trying to solve. It helps users of your code handle specific error cases:

#[derive(Debug)]
enum AdventOfCodeError {
    IoError(std::io::Error),
    ParseError { line: String, error: ParseIntError },
    InvalidFormat(String),
}

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

The ? Operator is Your Friend here

The ? operator is perfect for propagating errors up the call stack. It's more concise than match or if let expressions and makes your code more readable. It means that an error can bubble up and declare itself.

fn process_data(input: &str) -> Result<u32, AdventOfCodeError> {
    let data = parse_input(input)?;
    let result = calculate_result(&data)?;
    Ok(result)
}

In this example, our function process_data returns either a number or a AdventOfCodeError. That error can come from either of the functions that are called in process_data: parse_input and calculate_result. We are using the ? operator here so say if you get an error in those functions, just pass the error up the call stack and return as an error from the process_data function.

Happy coding, and looking forward to seeing your Day 4 solutions! 🎄✨

P.S. If you want to see this in action, check out the documentation for std::result and error handling in the Rust book.

[hollygrimm]

My solution for day 4 🦀 ❤️

[CarolineMorton]

How did you find this? I haven't started yet

[Sowmiya07]

Here is my Day 4 Part 1 solution. I will find some time later this week to complete Part 2 as well.

I was able to add

1. extensive tests
2. modularizing the functions
3. Docstrings
4. ? operator and Result

[CarolineMorton]

Great to see - well done!

[em-baggie]

My solution to day 4 part 1. Found this one tough! Tried a lot of different ways until one worked. Thought about using ndarray but couldn't find clear documentation. Included testing/docstrings as per advice from @CarolineMorton and custom error handling. Adapted the custom error handling from @hollygrimm's solution to help me learn - hope you don't mind!! Will try to come back to part 2 later.

[CarolineMorton]

Sharing is caring here!

[DominikStefancik]

My solution for the day 4. This time the first part was more complicated than the second one 😅

[kuhmil]

Found the words but could not find correct amount of 'X' shapes. Here is Part 1 of Day 4 as I have not been able to figure out Part 2!