0

After a brief attempt, when I run the the Rustling test for exercises/error_handling/errorsn.rs, I get

---- test_ioerror stdout ----
thread 'test_ioerror' panicked at 'assertion failed: `(left == right)`
  left: `"uh-oh!"`,
 right: `"cannot parse integer from empty string"`', exercises/error_handling/errorsn.rs:69:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Line 69 has

assert_eq!("uh-oh!", read_and_validate(&mut b).unwrap_err().to_string());

Doing a bit of debugging I can see read_and_validate(&mut b) is returning,

Err(ParseIntError { kind: Empty })

My first attempt to remedy this was,

let num: i64 = line.trim().parse().or(Err("uh-oh!")?;

But this seemed senselessly awkward looking for uh-oh! in the code I saw,

Err(io::Error::new(io::ErrorKind::BrokenPipe, "uh-oh!"))

So I could tell at this point I wasn't supposed to write "uh-oh!" anywhere. Looking at the cause for my error, the bugged code they provide (which we're supposed to fix) has,

b.read_line(&mut line); # unmodified notice they don't have `?`

What I had to do was change it to the following,

b.read_line(&mut line)?; # I added the `?`
let num: i64 = line.trim().parse()?;

While that's all easy, it doesn't make sense. Looking up .read_line I see it returns a Result.

So my question at the end of all this is why do callers of .read_line not have to handle the errors it returns? It seems like the lesson from this Rustlings is almost trolling the user to tell them you can't rely on type-safety. Look at the docs, all of this seems to be undocumented. Rust even has a section entitled "Results must be used",

Result is annotated with the #[must_use] attribute, which will cause the compiler to issue a warning when a Result value is ignored. This makes Result especially useful with functions that may encounter errors but don't otherwise return a useful value. [...] If you do write that in Rust, the compiler will give you a warning (by default...

Where is this behavior documented? What other core functions allow errors to go unhandeld?

Evan Carroll
  • 78,363
  • 46
  • 261
  • 468
  • `?` is you explicitly using the `Result`. Whatever function is calling `read_line` would also be returning a `Result` so somewhere that is handled. Maybe if you expand your question with details about the caller, someone can provide a clearer answer? – loganfsmyth May 06 '20 at 03:44
  • My question is why when I don't use the result does this even compile? `.read_line` would otherwise be returning a result that I'm not using. It makes sense to require `b.read_line(&mut line)?;` It doesn't make sense to me why `b.read_line(&mut line);` is even permitted. – Evan Carroll May 06 '20 at 03:48
  • 2
    Unused `Result` is not an error, but a warning. Add `#![deny(warnings)]` to the top of `lib.rs`, and the original variant should fail. – Cerberus May 06 '20 at 03:49
  • Ah, I see what's happening. Normally I must mentally treat these warnings as Errors. I didn't know it even compiled when you did this. Now I don't get a warning at all. So Rustlings must be eating the compiler warnings, which makes it more difficult to use Rustlings than Rust proper. – Evan Carroll May 06 '20 at 03:51

1 Answers1

6

Rustlings does not show compiler warnings.

What you would normally see are warnings, not errors. Rustlings does not reflect compiler warnings to the end user. So you see nothing.

If you want to see the warnings, add

#![deny(warnings)]

However, there are a lot of warnings in the Rustlings code so it seems that that warning won't be promoted before one of the other warnings-promoted-to-errors stops compilation. Also rustlings watch will stop watching the second it encounters an error.

Evan Carroll
  • 78,363
  • 46
  • 261
  • 468