feat(errors): Improve comments and hints

exercises/error_handling/errors1.rs

@@ -3,7 +3,7 @@
 // you pass it an empty string. It'd be nicer if it explained what the problem
 // was, instead of just sometimes returning `None`. Thankfully, Rust has a similar
 // construct to `Option` that can be used to express error conditions. Let's use it!
-// Execute `rustlings hint errors1` for hints!
+// Execute `rustlings hint errors1` or use the `hint` watch subcommand for a hint.
 
 // I AM NOT DONE
 

exercises/error_handling/errors2.rs

@@ -14,7 +14,8 @@
 // and add.
 
 // There are at least two ways to implement this that are both correct-- but
-// one is a lot shorter! Execute `rustlings hint errors2` for hints to both ways.
+// one is a lot shorter!
+// Execute `rustlings hint errors2` or use the `hint` watch subcommand for a hint.
 
 // I AM NOT DONE
 

exercises/error_handling/errors3.rs

@@ -2,7 +2,7 @@
 // This is a program that is trying to use a completed version of the
 // `total_cost` function from the previous exercise. It's not working though!
 // Why not? What should we do to fix it?
-// Execute `rustlings hint errors3` for hints!
+// Execute `rustlings hint errors3` or use the `hint` watch subcommand for a hint.
 
 // I AM NOT DONE
 

exercises/error_handling/errors4.rs

@@ -1,5 +1,5 @@
 // errors4.rs
-// Make this test pass! Execute `rustlings hint errors4` for hints :)
+// Execute `rustlings hint errors4` or use the `hint` watch subcommand for a hint.
 
 // I AM NOT DONE
 
@@ -14,6 +14,7 @@ enum CreationError {
 
 impl PositiveNonzeroInteger {
     fn new(value: i64) -> Result<PositiveNonzeroInteger, CreationError> {
+        // Hmm...? Why is this only returning an Ok value?
         Ok(PositiveNonzeroInteger(value as u64))
     }
 }

exercises/error_handling/errors5.rs

@@ -12,7 +12,7 @@
 
 // What can we use to describe both errors? In other words, is there a trait which both errors implement?
 
-// Execute `rustlings hint errors5` for hints!
+// Execute `rustlings hint errors5` or use the `hint` watch subcommand for a hint.
 
 // I AM NOT DONE
 

exercises/error_handling/errors6.rs

@@ -6,7 +6,7 @@
 // we define a custom error type to make it possible for callers to decide
 // what to do next when our function returns an error.
 
-// Make these tests pass! Execute `rustlings hint errors6` for hints :)
+// Execute `rustlings hint errors6` or use the `hint` watch subcommand for a hint.
 
 // I AM NOT DONE
 
@@ -20,7 +20,11 @@ enum ParsePosNonzeroError {
 }
 
 impl ParsePosNonzeroError {
+    fn from_creation(err: CreationError) -> ParsePosNonzeroError {
+        ParsePosNonzeroError::Creation(err)
+    }
     // TODO: add another error conversion function here.
+    // fn from_parseint...
 }
 
 fn parse_pos_nonzero(s: &str)

info.toml

@@ -603,7 +603,10 @@ name = "errors3"
 path = "exercises/error_handling/errors3.rs"
 mode = "compile"
 hint = """
-If other functions can return a `Result`, why shouldn't `main`?"""
+If other functions can return a `Result`, why shouldn't `main`? It's a fairly common
+convention to return something like Result<(), ErrorType> from your main function.
+The unit (`()`) type is there because nothing is really needed in terms of positive
+results."""
 
 [[exercises]]
 name = "errors4"