Using color_eyre and distributed tracing to yield better error messages to the user

Chris Biscardi
InstructorChris Biscardi
Share this video with your friends

Social Share Links

Send Tweet
Published 3 years ago
Updated 3 years ago

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

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, 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.

~ an hour ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today