-
Notifications
You must be signed in to change notification settings - Fork 302
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
Add http::Error::inner_ref and cause #303
Conversation
Also use `Error::inner_ref` to implement `std::error::Error::cause` for now. When MSRV is raised to 1.30.0+, this could also be used for `Error::source` without a breaking change.
Thanks for the PR. I commented on the original issue. I think a downcasting strategy is fine, but the details should be tweaked. I commented on the original issue. |
We could add a |
@seanmonstar not following. The way I'm seeing it, the question is if So, should the inner error be exposed via |
As tested, one can also call I think this has a slight advantage, also in that it implements |
That's a fair point. Also, re-reading through the builder PR, it mentioned that if one wanted to handle specific errors, one could check for the errors before passing to the builder, like |
All the inner errors are currently public, exported types, because when not using builders, these are the error types returned. If some private inner errors were added in the future, users just wouldn't be able to name and cast these.
I could add that here, but am concerned about complicating things, e.g. adding a version_check build dependency. The alternative is use standard |
Not sure if I missed answering some open question in your consideration of this PR (or if the associated issue is valid)? @carllerche wrote:
I suggest that the inner error should be exposed (by reference from http::Error) because it is the "real" error, or more specifically, because it is the only error that gives some specific indication of the problem, beyond the @seanmonstar wrote:
Assuming that it is possible to preempt all
Said another way: having a single Or, what's the argument for leaving |
Why did we go silent on this? I am comfortable adding a build.rs and version_check build dep to this PR, to implement Would you like to clarify or otherwise give me a hint if such a modified PR would be merged? Thanks for your consideration! |
Sorry for dropping the ball, I was out for the week thanks to a small procedure. Let's get back to this. I think @carllerche was saying it shouldn't be The question is what should we expose for |
I won't belabor this, but I don't really follow the distinction being made, re: "is" the error. Recommendations (incl by error/failure/quick/chain libs) all seem to implement I added 2d88403 to demonstrate an |
@dekellum The main difference is what happens when |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost there 👍
None of the inner errors currently have a cause, but this is considered (see PR discussion) the most correct implementation of `std::error::Error::cause` and is thus future proofed.
I'll be out of town myself for the next 2 weeks, so if you need more changes, unfortunately I will be further delayed in responding. Thanks. |
Thanks for pushing on this! |
Fixes #302
Provides access by reference to the inner error type.
Also uses
Error::inner_ref
to implementstd::error::Error::cause
, for now. When MSRV is raised to 1.30.0+, this could be used forError::source
instead, without any breaking change.