3 ms·

Thanks for the clarification. I get what you're saying, but I wouldn't write it like this - I'd write more code with more checks ;) In terms of errors, though,

Thanks for the clarification. I get what you're saying, but I wouldn't write it like this - I'd write more code with more checks ;) In terms of errors, though, it's generally "the result is either a value and no error, or no value and one of these errors". I get how sum types would help with this, and I'm not arguing against that; they would be useful. But the pattern matching basically still has to deal with that outcome, and have a pattern for each error type. It doesn't strike me as being inherently safer, more readable, etc.

justinpombrio 3y ago
> But the pattern matching basically still has to deal with that outcome, and have a pattern for each error type. Not so! In Rust: enum FileError { FileNotFound, FileExplodedWhileOpening, } impl Display for FileError { ... } // say how to print the errors // Result is defined in the standard library. // It's used to store results that may be successful, or may be an error: enum Result<Success, Error> { Ok(Success), Err(Error), } fn read_file(path: Path) -> Result<File, FileError> { ... } fn main() { match read_file("kittens.png") { Ok(file) => // show kittens on screen Err(err) => println!("Could not show kittens :-( \n{}", err), } }