Clean up and unify exercises

exercises/13_error_handling/errors1.rs

@@ -1,13 +1,8 @@
-// errors1.rs
-//
 // This function refuses to generate text to be printed on a nametag if 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` or use the `hint` watch subcommand for a
-// hint.
 
 fn main() {
     // You can optionally experiment here.

exercises/13_error_handling/errors2.rs

@@ -1,5 +1,3 @@
-// errors2.rs
-//
 // Say we're writing a game where you can buy items with tokens. All items cost
 // 5 tokens, and whenever you purchase items there is a processing fee of 1
 // token. A player of the game will type in how many items they want to buy, and
@@ -15,9 +13,6 @@
 //
 // There are at least two ways to implement this that are both correct-- but one
 // is a lot shorter!
-//
-// Execute `rustlings hint errors2` or use the `hint` watch subcommand for a
-// hint.
 
 use std::num::ParseIntError;
 

exercises/13_error_handling/errors3.rs

@@ -1,11 +1,6 @@
-// errors3.rs
-//
 // 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` or use the `hint` watch subcommand for a
-// hint.
 
 use std::num::ParseIntError;
 

exercises/13_error_handling/errors4.rs

@@ -1,8 +1,3 @@
-// errors4.rs
-//
-// Execute `rustlings hint errors4` or use the `hint` watch subcommand for a
-// hint.
-
 #[derive(PartialEq, Debug)]
 struct PositiveNonzeroInteger(u64);
 
@@ -23,12 +18,17 @@ fn main() {
     // You can optionally experiment here.
 }
 
-#[test]
-fn test_creation() {
-    assert!(PositiveNonzeroInteger::new(10).is_ok());
-    assert_eq!(
-        Err(CreationError::Negative),
-        PositiveNonzeroInteger::new(-10)
-    );
-    assert_eq!(Err(CreationError::Zero), PositiveNonzeroInteger::new(0));
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn test_creation() {
+        assert!(PositiveNonzeroInteger::new(10).is_ok());
+        assert_eq!(
+            Err(CreationError::Negative),
+            PositiveNonzeroInteger::new(-10)
+        );
+        assert_eq!(Err(CreationError::Zero), PositiveNonzeroInteger::new(0));
+    }
 }

exercises/13_error_handling/errors5.rs

@@ -1,5 +1,3 @@
-// errors5.rs
-//
 // This program uses an altered version of the code from errors4.
 //
 // This exercise uses some concepts that we won't get to until later in the
@@ -18,9 +16,6 @@
 //
 // What can we use to describe both errors? In other words, is there a trait
 // which both errors implement?
-//
-// Execute `rustlings hint errors5` or use the `hint` watch subcommand for a
-// hint.
 
 use std::error;
 use std::fmt;

exercises/13_error_handling/errors6.rs

@@ -1,13 +1,8 @@
-// errors6.rs
-//
 // Using catch-all error types like `Box<dyn error::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.
-//
-// Execute `rustlings hint errors6` or use the `hint` watch subcommand for a
-// hint.
 
 use std::num::ParseIntError;