Update description

exercises/13_error_handling/errors7.rs

@@ -1,8 +1,8 @@
-// TODOUsing catch-all error types like `Box<dyn Error>` isn't recommended for
+// While defining and using a custom error type in library code is recomended
-// library code where callers might want to make decisions based on the error
+// the ergonomics of the map_err approach presented in errors6 is suboptimal.
-// content instead of printing it out or propagating it further. Here, we define
+// The growing codebase could quickly become obfuscated by error conversions
-// a custom error type to make it possible for callers to decide what to do next
+// sprinkled here and there. Fortunetly, using traits we just learned about,
-// when our function returns an error.
+// we can use one more Rust feature to fix that.
 
 use std::num::ParseIntError;
 
@@ -29,13 +29,16 @@ impl ParsePosNonzeroError {
     }
 }
 
-// TODO Implement From trait for ParseIntError and CreationError
+// TODO Implement From trait for ParseIntError
 // impl From<ParseIntError> for ParsePosNonzeroError {
 //     fn from(err: ParseIntError) -> Self {
 //        ???
 //     }
 // }
 
+// TODO Implement From trait for CreationError
+// ...
+
 #[derive(PartialEq, Debug)]
 struct PositiveNonzeroInteger(u64);
 
@@ -49,9 +52,9 @@ impl PositiveNonzeroInteger {
     }
 
     fn parse(s: &str) -> Result<Self, ParsePosNonzeroError> {
-        // Return an appropriate error instead of panicking when `parse()`
+        // Don't change this line
-        // returns an error.
         let x: i64 = s.parse()?;
+        // Don't change this line
         Self::new(x)?
     }
 }

rustlings-macros/info.toml

@@ -760,7 +760,7 @@ The `+` operator can concatenate a `String` with a `&str`."""
 name = "errors7"
 dir = "13_error_handling"
 hint = """
-More about relatio between try operator and From Trait:
+More about relation between try operator and the From trait:
 https://doc.rust-lang.org/std/convert/trait.From.html#examples"""
 
 [[exercises]]

solutions/13_error_handling/errors7.rs

@@ -1,8 +1,8 @@
-// Using catch-all error types like `Box<dyn Error>` isn't recommended for
+// While defining and using a custom error type in library code is recomended
-// library code where callers might want to make decisions based on the error
+// the ergonomics of the map_err approach presented in errors6 is suboptimal.
-// content instead of printing it out or propagating it further. Here, we define
+// The growing codebase could quickly become obfuscated by error conversions
-// a custom error type to make it possible for callers to decide what to do next
+// sprinkled here and there. Fortunetly, using traits we just learned about,
-// when our function returns an error.
+// we can use one more Rust feature to fix that.
 
 use std::num::ParseIntError;
 
@@ -54,9 +54,9 @@ impl PositiveNonzeroInteger {
     }
 
     fn parse(s: &str) -> Result<Self, ParsePosNonzeroError> {
-        // Return an appropriate error instead of panicking when `parse()`
+        // Don't change this line
-        // returns an error.
         let x: i64 = s.parse()?;
+        // Don't change this line
         Self::new(x)?
     }
 }