Using color_eyre and distributed tracing to yield better error messages to the user
Right now we are using the todo!() macro which is great for simulating when our program panics. The error message that we get can be improved upon.
We will look at color-eyre that will allow us to handle the errors we receive to be more visual and human-readable.
The todo! macro is useful and it also exposes what
happens if our application panics.
thread 'main' panicked at 'not yet implemented', src/main.rs:2:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
This could be both more readable and contain more information while also being colored using color_eyre.
The application panicked (crashed).
Message: not yet implemented
Location: src/main.rs:5
Backtrace omitted.
Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
We'll use cargo-edit to add the package to our Cargo.toml.
cargo install cargo-edit
cargo add color_eyre
main can return Result, so we'll use color_eyre's
Result as our return value and color_eyre::install to
install the default panic and error reporting hooks.
install returns a Result so we can use ? to handle
any errors if necessary.
We haven't shown off everything that color_eyre is capable of. In addition to panic handling, color_eyre allows us to track additional information in the context of our errors and include suggestions by taking advantage of distributed tracing infrastructure.
We'll see more of how this helps as we build out the CLI.
Instructor: [0:00] The todo macro is quite useful and exposes what happens if future functionality in our program panics. This could be more readable and also contain more information while also including more colors. To achieve this, we'll use color-eyre.
[0:19] Color-eyre includes an error report handler that we can attach to our main function that handle things like panics and errors in a more visual way. Since we will have actual human users using our CLI, this will make for a better user experience.
[0:36] If you're used to other package managers with add, remove, and upgrade functionality like npm or Yarn, you'll want to use cargo-edit. By using cargo install cargo-edit, we gain access to the add, remove, and upgrade subcommands. I already have it installed, but you'll see a slightly different output when you install.
[0:56] Now that we have cargo-edit installed, we'll do, cargo add color-eyre. Note that I mistyped the package name with an underscore instead of a dash. This is a fairly common mistake for me to make. I'm happy that cargo-edit handles this for me.
[1:12] If we look at the dependencies in our cargo.toml, we'll see color-eyre specified as .5.10. While we don't have to use color-eyre error result to be able to use it in our type signatures, we'll do it here to make our type signature a little bit shorter and make it easier to use the result type in future functions.
[1:33] If you're less familiar with how use works, note that it's not actually an import, and that writing the full path in the type signature will achieve the same result. We modified our main function to return a result with a value of unit. We aren't allowed to return anything other than unit inside of the result here.
[1:54] For more information about how result works and why it works, you can read question mark in main and tests in the Rust Edition Guide. Note that, like we've said before, we don't actually have to use different exports. We can use the fully qualified path instead.
[2:12] In this case, we'll use the color-eyre install function. On docs.rs, we're going to search for Install. Click the Install function, and see what the return type is. In this case, Install picks no arguments and returns a result of unit and report. This is the same type that we have in our return type of our main function.
[2:36] We can use a question mark to propagate the error back up to our main function if this function fails. Otherwise, we can just continue with our program.
[2:46] Now when we cargo run, we'll see color-eyre getting downloaded. After our program is built and run, we'll see that there's new output. We can see the source location, including the file and the line number. We can see the message that was created from our todo Macro. We can see some of the application panic crash output.
[3:09] As we move forward in building out our CLI, different errors will add additional contexts to these error messages. This will make it such that if a file doesn't exist, for example, we know which file we're looking for and why, as opposed to just saying, "File doesn't exist. Fail."
[3:29] We haven't shown off everything that color-eyre can do here. In addition to panic handling, color-eyre allows us to track additional information in a context of our errors and includes suggestions for what to do, like taking advantage of the distributed tracing infrastructure that the Tokio project has produced. We'll see more of how this helps as we build out the CLI.