feat(errors): Improve comments and hints

This commit is contained in:
mokou 2022-07-14 18:02:33 +02:00
parent 5e1ca4b995
commit c34e2adcbb
7 changed files with 16 additions and 7 deletions

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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))
}
}

View File

@ -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

View File

@ -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)

View File

@ -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"