Master Result, the ? operator, anyhow for applications, thiserror for libraries, and when to panic vs propagate errors.
0 / 5 completed
1 / 5
What does the Result<T, E> type represent in Rust?
Result type: Rust has no exceptions. Functions that can fail return Result<T, E>. The compiler forces callers to handle or propagate both variants — you cannot accidentally ignore an error. The ? operator provides ergonomic propagation: let data = read_file()?; returns the error from the current function if it occurs.
2 / 5
What does the ? operator do when used on a Result in Rust?
? operator:let n: u32 = "42".parse()?; returns Err(ParseIntError) to the caller if parsing fails. The From trait converts the error type automatically if needed. This replaces verbose match blocks for propagation, keeping error-handling code concise while remaining explicit about failure paths.
3 / 5
What does the anyhow crate provide for error handling?
anyhow: library code should return specific error types so callers can match them. Application code (CLI tools, servers) often just needs to propagate and display errors. use anyhow::Result; fn run() -> Result<()> { let f = File::open("config.json").context("opening config")?; } adds human-readable context to any error.
4 / 5
What does the thiserror crate provide?
thiserror:#[derive(Error, Debug)] pub enum DbError { #[error("connection failed: {0}")] Connection(#[from] io::Error), #[error("query failed")] Query }. The #[error("...")] attribute generates Display; #[from] generates From<io::Error> for DbError. Callers can match on specific variants.
5 / 5
When should you use panic! versus returning an Err in Rust?
panic vs Err: panics unwind the stack (or abort) and are not recoverable in normal application flow. Use them for assertions about program correctness: unreachable!(), assert!(). Return Err for conditions callers are expected to encounter and handle — like invalid user input or transient I/O failures.