error-stack: thiserror #[derive(Context)]

[dpc]

It seems I'll have to do a lot of impl Context for SomeError {}. Wouldn't it be nice if we had a derive for it?

[TimDiekmann]

We thought about this as well but decided that currently, it's not helpful to copy thiserror.

Unless you want to implement Context::provide(), or you are in no-std there is no reason to not use thiserrors macro. For the former case, we couldn't come up with a good solution to implement provide(), for the latter case I expect this to be solved in the near future when Error is moved to core.

Do you have a concrete suggestion on implementing Context with provide()?

I can think of a macro that is able to attach objects similar to tracing::instrument, but we didn't decide on a syntax, yet, as attachments have no key/value pair like instrument. Suggestions are very welcome! 🙂

---

Marking this as the answer for now. If someone has suggestions for concrete macro implementation please open a new discussion.

[dpc]

I'm so confused. I probably don't know what I'm talking about.

I have a lot of errors that look like this:

#[derive(Debug, Display)]
pub enum EnvError {
    #[display(fmt = "Could not load environment")]
    Load,
    [...]
}

pub type EnvResult<T> = Result<T, EnvError>;

impl Context for EnvError {}

My whole point is that this impl Context for EnvError {} (well, actually the pub type EnvResult<T> = Result<T, EnvError>; too) seem a bit boilerplate-y, and I was hoping I could get rid of if automatically.

I have no idea what the provide is for, at least not yet. :D

[TimDiekmann]

We currently have no plans to add #[derive(Context)] as this would do the same as any #[derive(Display)] + impl Context, or #[derive(thiserror::Error)]. Using thiserror fits very well, as it's not appearing in the public API. You could simply create your error types using thiserror and use error-stack as the error handling library.

[dpc]

OOOOOOOOhhhhhh... all Errors implement Context automatically...

I've been using derive_more::Display + impl Context indeed. :D

[Alfred-Mountfield]

And just to add a little clarification in case it was missing. If you wanted to implement provide and use it later on, you have to do that inside the Context impl, which is why we didn't want to just do a normal derive without a provide impl.

Glad you've got another approach that works for you though! We can perhaps try and update the docs or examples to make it a little clearer that implementing Error (by using thiserror or whatever) gives you Context automatically.

[dpc]

I can't point out exactly why, but I had to hit a lot of problems before I kind of (hopefully) understood how to use this library.

Possibly it's because the documentation (at least the one I was looking at, including the original anouncement). is too focus on on explaining why and advanced use cases, and there was less of "this is a best practice example".

All I need to know is: take thiserror, use it as before, but your Error in Result will get wrapped in a Context, and you'll have to add .report() and .change_context here and there.