errorsn.rs: Separate also the hints from each other to avoid accidental viewing

Signed-off-by: Eddy Petrisor <eddy.petrisor@gmail.com>
This commit is contained in:
Eddy Petrisor 2019-05-23 12:21:25 +03:00
parent 9aec4abc4d
commit f507844102
1 changed files with 76 additions and 0 deletions

View File

@ -146,11 +146,49 @@ impl error::Error for CreationError {
// `read_and_validate` returns and`test_with_str` has its signature fully
// specified.
// Next hint: There are three places in `read_and_validate` that we call a
// function that returns a `Result` (that is, the functions might fail).
// Apply the `?` operator on those calls so that we return immediately from
// `read_and_validate` if those function calls fail.
// Another hint: under the hood, the `?` operator calls `From::from`
// on the error value to convert it to a boxed trait object, a Box<error::Error>,
// which is polymorphic-- that means that lots of different kinds of errors
@ -159,12 +197,50 @@ impl error::Error for CreationError {
// Check out this section of the book:
// https://doc.rust-lang.org/stable/book/second-edition/ch09-02-recoverable-errors-with-result.html#a-shortcut-for-propagating-errors-the--operator
// Another another hint: Note that because the `?` operator returns
// the *unwrapped* value in the `Ok` case, if we want to return a `Result` from
// `read_and_validate` for *its* success case, we'll have to rewrap a value
// that we got from the return value of a `?`ed call in an `Ok`-- this will
// look like `Ok(something)`.
// Another another another hint: `Result`s must be "used", that is, you'll
// get a warning if you don't handle a `Result` that you get in your
// function. Read more about that in the `std::result` module docs: