From 15616bc09bd7ab6e785680a364364e962c57bb21 Mon Sep 17 00:00:00 2001 From: JirCep Date: Wed, 3 Aug 2022 22:14:44 +0200 Subject: [PATCH 1/2] `expect` is not used multitude times by this chapter --- ...2-03-improving-error-handling-and-modularity.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/ch12-03-improving-error-handling-and-modularity.md b/src/ch12-03-improving-error-handling-and-modularity.md index 87e525d122..961246be62 100644 --- a/src/ch12-03-improving-error-handling-and-modularity.md +++ b/src/ch12-03-improving-error-handling-and-modularity.md @@ -23,13 +23,13 @@ example, the file could be missing, or we might not have permission to open it. Right now, regardless of the situation, we’d print the same error message for everything, which wouldn’t give the user any information! -Fourth, we use `expect` repeatedly to handle different errors, and if the user -runs our program without specifying enough arguments, they’ll get an `index out -of bounds` error from Rust that doesn’t clearly explain the problem. It would -be best if all the error-handling code were in one place so future maintainers -had only one place to consult the code if the error-handling logic needed to -change. Having all the error-handling code in one place will also ensure that -we’re printing messages that will be meaningful to our end users. +Fourth, if the user runs our program without specifying enough arguments, +they’ll get an `index out of bounds` error from Rust that doesn’t clearly +explain the problem. It would be best if all the error-handling code were +in one place so future maintainers had only one place to consult the code +if the error-handling logic needed to change. Having all the error-handling +code in one place will also ensure that we’re printing messages that +will be meaningful to our end users. Let’s address these four problems by refactoring our project. From 54726034c5b4c7e865128a3047bc97eba15e8eb3 Mon Sep 17 00:00:00 2001 From: Chris Krycho Date: Fri, 19 Apr 2024 13:35:31 -0600 Subject: [PATCH 2/2] Ch. 12.3: be clearer about how `expect` was used --- ...2-03-improving-error-handling-and-modularity.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/ch12-03-improving-error-handling-and-modularity.md b/src/ch12-03-improving-error-handling-and-modularity.md index 961246be62..1b67d63d6d 100644 --- a/src/ch12-03-improving-error-handling-and-modularity.md +++ b/src/ch12-03-improving-error-handling-and-modularity.md @@ -23,13 +23,13 @@ example, the file could be missing, or we might not have permission to open it. Right now, regardless of the situation, we’d print the same error message for everything, which wouldn’t give the user any information! -Fourth, if the user runs our program without specifying enough arguments, -they’ll get an `index out of bounds` error from Rust that doesn’t clearly -explain the problem. It would be best if all the error-handling code were -in one place so future maintainers had only one place to consult the code -if the error-handling logic needed to change. Having all the error-handling -code in one place will also ensure that we’re printing messages that -will be meaningful to our end users. +Fourth, we use `expect` to handle an error, and if the user runs our program +without specifying enough arguments, they’ll get an `index out of bounds` error +from Rust that doesn’t clearly explain the problem. It would be best if all the +error-handling code were in one place so future maintainers had only one place +to consult the code if the error-handling logic needed to change. Having all the +error-handling code in one place will also ensure that we’re printing messages +that will be meaningful to our end users. Let’s address these four problems by refactoring our project.