Provide stack traces for runtime errors.

[XAMPPRocky]

Currently we use thiserror for defining errors. This is pretty good, as it has minimal boilerplate for passing up errors in the library. However when we print the errors they are currently a bit lacking in enough context to make them useful. For example; Errors do not currently print stack traces, which makes it a lot harder to debug errors at runtime, since something like RecvError(()) can happen in a lot of places.

To get these features, it would be quickest and simplest to move to a different error library. My preference would be for using eyre, but I don't know if other people feel strongly either way.

[markmandel]

Just looking at thiserror - we could include backtraces by ensuring the field is part of our Error types:
https://docs.rs/thiserror/1.0.30/thiserror/#details

My concern with eyre from what I can see there is no derive macro, so we don't get to keep our own Error types (all our error types become eyre::Report)-- and having our own Error types is optimal when using Quilkin as a library.

which makes it a lot harder to debug errors at runtime, since something like RecvError(()) can happen in a lot of places.

🤔 that seems like that is not a good error? Sounds like something we should fixup so they are more explicit as well.

[markmandel]

Just looking at thiserror - we could include backtraces by ensuring the field is part of our Error types: https://docs.rs/thiserror/1.0.30/thiserror/#details

On review, it looks like this only works with nightly Rust? 😞 Doesn't look like they are keen on incorporating https://crates.io/crates/backtrace either. 🤔

[XAMPPRocky]

My concern with eyre from what I can see there is no derive macro, so we don't get to keep our own Error types (all our error types become eyre::Report)-- and having our own Error types is optimal when using Quilkin as a library.

Sorry, I shouldn't have said move, because we'd still use thiserror for defining the error. From the eyre docs:

Eyre works with any error type that has an impl of std::error::Error, including ones defined in your crate. We do not bundle a derive(Error) macro but you can write the impls yourself or use a standalone macro like thiserror.

What would change is our return type, we'd start returning Result<T, eyre::Report>, and eyre::Report will wrap around the existing error types. It does also have the nice side benefit of removing the need for error wrapper variants (e.g. Io(std::io::Error)) since any error type can be converted into a Report, you can use ? on any Result<T, impl std::error::Error> function without having to call map_err first.