From d8babf9a5367fd24addafa05c1fba82498959a47 Mon Sep 17 00:00:00 2001
From: Grzegorz Dziadkiewicz <grzegorzdziadkiewicz@gmail.com>
Date: Sun, 12 Jan 2025 11:50:18 +0100
Subject: [PATCH] Update description

---
 exercises/13_error_handling/errors7.rs | 19 +++++++++++--------
 rustlings-macros/info.toml             |  2 +-
 solutions/13_error_handling/errors7.rs | 14 +++++++-------
 3 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/exercises/13_error_handling/errors7.rs b/exercises/13_error_handling/errors7.rs
index 4d9affbb..446f48ec 100644
--- a/exercises/13_error_handling/errors7.rs
+++ b/exercises/13_error_handling/errors7.rs
@@ -1,8 +1,8 @@
-// TODOUsing catch-all error types like `Box<dyn Error>` isn't recommended for
-// library code where callers might want to make decisions based on the error
-// content instead of printing it out or propagating it further. Here, we define
-// a custom error type to make it possible for callers to decide what to do next
-// when our function returns an error.
+// While defining and using a custom error type in library code is recomended
+// the ergonomics of the map_err approach presented in errors6 is suboptimal.
+// The growing codebase could quickly become obfuscated by error conversions
+// sprinkled here and there. Fortunetly, using traits we just learned about,
+// 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()`
-        // returns an error.
+        // Don't change this line
         let x: i64 = s.parse()?;
+        // Don't change this line
         Self::new(x)?
     }
 }
diff --git a/rustlings-macros/info.toml b/rustlings-macros/info.toml
index f1f2ecef..54705b61 100644
--- a/rustlings-macros/info.toml
+++ b/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]]
diff --git a/solutions/13_error_handling/errors7.rs b/solutions/13_error_handling/errors7.rs
index 61464042..534d13ed 100644
--- a/solutions/13_error_handling/errors7.rs
+++ b/solutions/13_error_handling/errors7.rs
@@ -1,8 +1,8 @@
-// Using catch-all error types like `Box<dyn Error>` isn't recommended for
-// library code where callers might want to make decisions based on the error
-// content instead of printing it out or propagating it further. Here, we define
-// a custom error type to make it possible for callers to decide what to do next
-// when our function returns an error.
+// While defining and using a custom error type in library code is recomended
+// the ergonomics of the map_err approach presented in errors6 is suboptimal.
+// The growing codebase could quickly become obfuscated by error conversions
+// sprinkled here and there. Fortunetly, using traits we just learned about,
+// 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()`
-        // returns an error.
+        // Don't change this line
         let x: i64 = s.parse()?;
+        // Don't change this line
         Self::new(x)?
     }
 }