X-Git-Url: https://git.ralfj.de/rust-101.git/blobdiff_plain/369875f931d841112dd2b6651fc968bb6c569cdb..4816335a8c0e5bcb2514d9c7857596348fa72ff4:/src/part03.rs?ds=inline diff --git a/src/part03.rs b/src/part03.rs index 45caaec..0e7db1d 100644 --- a/src/part03.rs +++ b/src/part03.rs @@ -56,14 +56,15 @@ fn read_vec() -> Vec { // of the function), but that's a bit too much magic for my taste. We are being more explicit here: // `parse::` is `parse` with its generic type set to `i32`. match line.parse::() { - // `parse` returns again a `Result`, and this time we use a `match` to handle errors (like, the user entering - // something that is not a number). - // This is a common pattern in Rust: Operations that could go wrong will return `Option` or `Result`. - // The only way to get to the value we are interested in is through pattern matching (and through helper functions - // like `unwrap()`). If we call a function that returns a `Result`, and throw the return value away, - // the compiler will emit a warning. It is hence impossible for us to *forget* handling an error, - // or to accidentally use a value that doesn't make any sense because there was an error producing it. + // `parse` returns again a `Result`, and this time we use a `match` to handle errors (like, the user entering + // something that is not a number). + // This is a common pattern in Rust: Operations that could go wrong will return `Option` or `Result`. + // The only way to get to the value we are interested in is through pattern matching (and through helper functions + // like `unwrap()`). If we call a function that returns a `Result`, and throw the return value away, + // the compiler will emit a warning. It is hence impossible for us to *forget* handling an error, + // or to accidentally use a value that doesn't make any sense because there was an error producing it. Ok(num) => vec.push(num), + // We don't care about the particular error, so we ignore it with a `_`. Err(_) => println!("What did I say about numbers?"), } }