error-stack: Something like #[from]in thiserror? (and include thiserro functionality with error-stack)

[dpc]

I understand that this crate tracks the chains of errors internally, so I don't have to wrap one error in another like I usually would.

However. It is kind of useful sometimes to be able to do that.

Eg. I have:

pub enum RequestError {
  WebhookValidationError(WebHookValidationError)
  ...
}

It is useful to that that validation error right there, and not have to do downcastings etc. to get it.

Even when using thiserror to derive things on RequestError, I can't just add #[from] because the function returning WebHookValidationError is now going to return Report<WebHookValidationError>.

I guess I can still just use std::result::Result for WebHookValidationResult, but that only works for cases where I don't care about using error-stack for it for some reason.

I hope it makes sense. Not a big deal, but might be something to think about. Maybe Report<C> could impl Into<C> or something like that.

And possibly error-stack just come up with it's own build-in thiserror-like macros. This way #[from] macro could just implement From<Report<E>> along the `From.

BTW. Having to combine these two (thiserror + error-stack) and documentation treating interactions between them kind of implicitly is already a steep learning curve. And it's also just an additional cargo add ... to run. IMO, just for this reason it would make sense to have it build-in, which would error-stack completely standalone solution.

[TimDiekmann]

Hi @dpc!

Even when using thiserror to derive things on RequestError, I can't just add #[from] because the function returning WebHookValidationError is now going to return Report<WebHookValidationError>.

That is one of the main reasons we have written error-stack. Each Report has a change_context method to change it's type. You can see more about this reasoning in the announcement blog post.

Maybe Report<C> could impl Into<C> or something like that.

A functionality to return the current context by value is planned. This is currently not implemented as a plain impl From<Report<C>> for C would drop all contexts and attachments, which defeats the point of using error-stack.

possibly error-stack just come up with it's own build-in thiserror-like macros. This way #[from] macro could just implement From<Report<E>> along the `From.

This will not happen unless someone comes up with a solution on how to implement Context::provide as mentioned in #746. In any case, there will be no From implementation. As mentioned above, error-stack is designed around Context and for this reason, change_context is provided. error-stack (and also anyhow or eyre) do not replace error types but wrap them. This is why From generally isn't a solution, otherwise you would create an error from a wrapper, not wrap the error.

Having to combine these two (thiserror + error-stack) and documentation treating interactions between them kind of implicitly is already a steep learning curve. And it's also just an additional cargo add ... to run. IMO, just for this reason, it would make sense to have it build-in, which would error-stack a completely standalone solution.

These two libraries serve two different purposes. error-stack uses Contexts and attachments to build around an existing error-like type. thiserror provides a derive macro for Error. You easily can drive error-stack without thiserror, which makes error-stack a completely standalone solution. We won't include thiserror in error-stack because this would give no benefits to anyone (adding one dependency does not count here) but instead, it would require us to maintain a whole additional part of a library which we did not write and is already maintained in form of another crate.
In the future we may provide a derive(Context) macro, but only if we come up with a solution to the problem mentioned in #746.

[dpc]

a plain impl From<Report<C>> for C would drop all contexts and attachments, which defeats the point of using error-stack.

But that's fine, in some contexts. For the same underlying error, one might want to sometimes bubble it up as report error-stack-style, and sometimes make it a part of another error this-error-style. That's what made me post it. I have an underlying error/function that I want to use in two different contexts - one user-facing (where I prefer pretty and informative errors), and one in http request handler (where Report is just getting in a way, and I want the upper-error to just compose the lower-error). I would be happy with any way to convert Report<C> back to C (and loosing attachments), it doesn't really have to be a blanket impl From.