Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using miette in a middleware trait definition #156

Closed
TheNeikos opened this issue Apr 21, 2022 · 5 comments
Closed

Using miette in a middleware trait definition #156

TheNeikos opened this issue Apr 21, 2022 · 5 comments
Labels
question Further information is requested

Comments

@TheNeikos
Copy link
Contributor

TheNeikos commented Apr 21, 2022

I currently have a trait akin to:

trait Middleware {
  fn handle(&self) -> Result<(), miette::Error>;
}

Which works fine until I try to use that Error in my own error reporting. I hit a couple of snags which I am not sure how to resolve:

  1. Error does not implement Diagnostic or std::error::Error, meaning that I can't use it in #[related] nor in thiserror::Error #[source] annotations. I could implement Diagnostic myself, but this is particularly 'annoying' in my case since its a enum with a dozen of error kinds.
  2. #[related] wants to see something that is IntoIterator but I usually just have a single error on which I want to add context. My current 'workaround' is to use a single element array, but it does look weird haha.

Now, these are just some painpoints I identified in this situation. I don't know if/how they come from my usage of the crate, but I still wanted to report my experience and potentially discuss solutions/changes that would make it easier to use here.

Thank you for making the crate!

@zkat
Copy link
Owner

zkat commented Apr 21, 2022

  1. This is correct, and intentional, because of How Type Stuff Works. Once you enter miette::Error (aka miette::Report) land, you can only downcast to specific errors. If you need to do this kind of thing, I suggest using a wrapper Diagnostic enum instead of miette::Error.
  2. I have feelings about #[related]. I think the API could be much better, and there's been some discussion over at severity(warning) should probably not use an Error: introducer #139 (comment), but nothing specific has come up as of yet.

Thanks for the comments, and I'm glad you're enjoying the crate! Stuff like this is super welcome :)

@zkat zkat added the question Further information is requested label Apr 21, 2022
@TheNeikos
Copy link
Contributor Author

I agree that it is not straightforward, but since Diagnostic implements AsRef for Diagnostic it is technically possible. I don't know how it could be done in an automated fashion though.

@TheNeikos
Copy link
Contributor Author

TheNeikos commented Apr 26, 2022

I've been thinking about your response @zkat, could you explain what you mean with a 'wrapper diagnostic enum'? I currently can't picture what you mean sadly.

I've also tried to use a Box<dyn Diagnostic> but I still can't use it as a source() since trait upcasting is still unstable in Rust :c

@zkat
Copy link
Owner

zkat commented Apr 26, 2022

http-types has an interesting solution for this, for the sake of handling the same scenario (dealing with dynamic errors in middleware).

I don't know what the ideal solution here is. I admit it's hard and I don't have a good answer, but I think the above is a good direction to try and head in and see how it feels.

@TheNeikos
Copy link
Contributor Author

I'd say that with the merging of #165 most of the pain points are gone and should work fine until the Provider API is there in some form. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants