Different Categories of Errors

When coding, we generally encounter two main types of errors: exceptions and failures. Exceptions are linked to the program's internal logic, such as the IndexError in Python or ArrayIndexOutOfBoundsException in Java, often stemming from bugs in the code. Conversely, failures are external issues, such as an inability to connect to a database or establish a TCP connection, which do not originate from programming errors but can often be resolved with repeated attempts.

In Python, both types of errors fall under the umbrella of Exceptions, complicating the differentiation and debugging processes.

In contrast, Rust categorizes errors into recoverable and unrecoverable errors:

• Unrecoverable errors (handled with panic!) indicate bugs, such as accessing an out-of-bounds index, and require immediate termination of the program.
• Recoverable errors (handled using Result) refer to issues like a missing file or a failed connection, allowing Rust to inform users and attempt to resolve the issue.

Unrecoverable Errors

In Rust, the panic! macro is employed to manage unrecoverable errors. Here’s a simple example:

The program will crash, notifying that the main thread has panicked. By setting RUST_BACKTRACE=1, we can view a detailed backtrace.

Besides panic!, several other macros facilitate early crashes:

• assert!(True == True); checks boolean conditions.
• assert_eq!(1, 2); compares two values, which can extend to complex data structures.
• unimplemented!(); serves a similar role to Python's pass, indicating a function that is not yet defined.
• unreachable!(); signals unreachable code.

Here’s an intriguing example from Rust's documentation:

#![allow(unused)]

fn main() {

#[allow(dead_code)]

fn divide_by_three(x: u32) -> u32 {

for i in 0.. {

if 3*i < i { panic!("u32 overflow"); }

if x < 3*i { return i-1; }

}

unreachable!("The loop should always return");

}

}

Commenting out the for loop leads to a panic when the program reaches the unreachable! part.

Recoverable Errors

Rust primarily utilizes a generic enum, Result, to manage recoverable errors. Let’s examine what each component of Result entails.

A common usage of Result is in function return values. For example, using std::fs::read to read a file returns a Vec format. If the specified file does not exist, it returns the error message "No such file or directory." Upon creating the file and executing the program again, the file's contents will be displayed.

Question Mark Operator

In scenarios where we prefer not to handle an error immediately, the question mark operator allows us to pass it along to another part of the program. This operator unwraps valid values or propagates error values to the calling function.

Here’s an illustration:

fn fizz() -> Result {

return Ok(0)

}

fn buzz() -> Result {

match fizz() {

Ok(a) => return Ok(a as i32),

Err(e) => return Err(e),

}

}

fn main(){

println!("{:?}", buzz());

}

The question mark operator can only be used when the error type matches that of the calling function. Changing the error type of the fizz function to String would yield an error.

Customizing Error Types

When invoking multiple functions from different libraries, each returning unique error types, we can encapsulate them into a custom error type. For example:

#[derive(Debug)]

pub enum Error {

IO(std::io::ErrorKind),

}

impl From<std::io::Error> for Error {

fn from(error: std::io::Error) -> Self {

Error::IO(error.kind())

}

}

fn do_read_file() -> Result<(), Error> {

let data = std::fs::read("/tmp/foo")?;

let data_str = std::str::from_utf8(&data).unwrap();

println!("{:?}", data_str);

Ok(())

}

fn main() {

do_read_file().unwrap();

}

In this example, we define an Error enum and implement a trait to convert standard library IO errors.

Upon execution, if the /tmp/foo file exists, its contents will be displayed. If it’s removed, a NotFound error will be triggered.

It's worth noting that in Rust, the main function can also return a value, namely Result<(), Error>. This means we can refactor main accordingly, ensuring to include an empty Ok(()) at the end.

fn main() -> Result<(), Error> {

do_read_file()?;

Ok(())

}