diff options
Diffstat (limited to 'exercises/error_handling')
| -rw-r--r-- | exercises/error_handling/errors1.rs | 14 | ||||
| -rw-r--r-- | exercises/error_handling/errors2.rs | 30 | ||||
| -rw-r--r-- | exercises/error_handling/errors3.rs | 5 | ||||
| -rw-r--r-- | exercises/error_handling/errors4.rs | 4 | ||||
| -rw-r--r-- | exercises/error_handling/errors5.rs | 36 | ||||
| -rw-r--r-- | exercises/error_handling/errors6.rs | 13 |
6 files changed, 60 insertions, 42 deletions
diff --git a/exercises/error_handling/errors1.rs b/exercises/error_handling/errors1.rs index bcee972..0ba59a5 100644 --- a/exercises/error_handling/errors1.rs +++ b/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 diff --git a/exercises/error_handling/errors2.rs b/exercises/error_handling/errors2.rs index 6971fcf..d86f326 100644 --- a/exercises/error_handling/errors2.rs +++ b/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 diff --git a/exercises/error_handling/errors3.rs b/exercises/error_handling/errors3.rs index a2d2d19..d42d3b1 100644 --- a/exercises/error_handling/errors3.rs +++ b/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 diff --git a/exercises/error_handling/errors4.rs b/exercises/error_handling/errors4.rs index 0efe8cc..e04bff7 100644 --- a/exercises/error_handling/errors4.rs +++ b/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 diff --git a/exercises/error_handling/errors5.rs b/exercises/error_handling/errors5.rs index eb5506c..92461a7 100644 --- a/exercises/error_handling/errors5.rs +++ b/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 diff --git a/exercises/error_handling/errors6.rs b/exercises/error_handling/errors6.rs index 8097b49..aaf0948 100644 --- a/exercises/error_handling/errors6.rs +++ b/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 |