docs: cleanup the explanation paragraphs at the start of each exercise.

exercises/error_handling/errors1.rs

@@ -1,9 +1,13 @@
 // 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.
+//
+// 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.
 
 // I AM NOT DONE
 

exercises/error_handling/errors2.rs

@@ -1,21 +1,23 @@
 // 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 the `total_cost` function will calculate the total cost of the tokens.
-// Since the player typed in the quantity, though, we get it as a string-- and
-// they might have typed anything, not just numbers!
-
+// token. A player of the game will type in how many items they want to buy, and
+// the `total_cost` function will calculate the total cost of the tokens. Since
+// the player typed in the quantity, though, we get it as a string-- and they
+// might have typed anything, not just numbers!
+//
 // Right now, this function isn't handling the error case at all (and isn't
-// handling the success case properly either). What we want to do is:
-// if we call the `parse` function on a string that is not a number, that
-// function will return a `ParseIntError`, and in that case, we want to
-// immediately return that error from our function and not try to multiply
-// 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` or use the `hint` watch subcommand for a hint.
+// handling the success case properly either). What we want to do is: if we call
+// the `parse` function on a string that is not a number, that function will
+// return a `ParseIntError`, and in that case, we want to immediately return
+// that error from our function and not try to multiply 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` or use the `hint` watch subcommand for a
+// hint.
 
 // I AM NOT DONE
 

exercises/error_handling/errors3.rs

@@ -1,8 +1,11 @@
 // 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.
+//
+// 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,7 @@
 // errors4.rs
-// Execute `rustlings hint errors4` or use the `hint` watch subcommand for a hint.
+//
+// Execute `rustlings hint errors4` or use the `hint` watch subcommand for a
+// hint.
 
 // I AM NOT DONE
 

exercises/error_handling/errors5.rs

@@ -1,20 +1,26 @@
 // 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 course, like `Box` and the
-// `From` trait. It's not important to understand them in detail right now, but you can read ahead if you like.
-// For now, think of the `Box<dyn ???>` type as an "I want anything that does ???" type, which, given
-// Rust's usual standards for runtime safety, should strike you as somewhat lenient!
-
-// In short, this particular use case for boxes is for when you want to own a value and you care only that it is a
-// type which implements a particular trait. To do so, The Box is declared as of type Box<dyn Trait> where Trait is the trait
-// the compiler looks for on any value used in that context. For this exercise, that context is the potential errors
-// which can be returned in a Result.
-
-// 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.
+//
+// This exercise uses some concepts that we won't get to until later in the
+// course, like `Box` and the `From` trait. It's not important to understand
+// them in detail right now, but you can read ahead if you like. For now, think
+// of the `Box<dyn ???>` type as an "I want anything that does ???" type, which,
+// given Rust's usual standards for runtime safety, should strike you as
+// somewhat lenient!
+//
+// In short, this particular use case for boxes is for when you want to own a
+// value and you care only that it is a type which implements a particular
+// trait. To do so, The Box is declared as of type Box<dyn Trait> where Trait is
+// the trait the compiler looks for on any value used in that context. For this
+// exercise, that context is the potential errors which can be returned in a
+// Result.
+//
+// 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.
 
 // I AM NOT DONE
 

exercises/error_handling/errors6.rs

@@ -1,12 +1,13 @@
 // 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.
+// 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.
 
 // I AM NOT DONE