feat(errors): Improve comments and hints
This commit is contained in:
parent
5e1ca4b995
commit
c34e2adcbb
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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))
|
||||
}
|
||||
}
|
||||
|
@ -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
|
||||
|
||||
|
@ -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)
|
||||
|
@ -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"
|
||||
|
Reference in New Issue
Block a user