-
Notifications
You must be signed in to change notification settings - Fork 261
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
client builder: return a ClientBuildError
when failing to build, instead of filtering out unexpected errors
#4016
client builder: return a ClientBuildError
when failing to build, instead of filtering out unexpected errors
#4016
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4016 +/- ##
==========================================
+ Coverage 84.25% 84.26% +0.01%
==========================================
Files 266 266
Lines 28344 28341 -3
==========================================
+ Hits 23880 23882 +2
+ Misses 4464 4459 -5 ☔ View full report in Codecov by Sentry. |
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.
Thanks for the PR. It's bad that you can hit this panic, I suppose it was put here as an internal-API error, and never supposed to be triggerable by users of the SDK. I think the code has evolved sufficiently that it's a bad idea for us to use assert_valid_builder_args
at all: the error could also be a store error, or a discovery error, or, or, or…
So instead, I think we should:
- get rid of
assert_valid_builder_args
- have
Client::new
return aResult<Self, ClientBuildError>
.
Are you willing to make the changes here? Otherwise one of us can probably get to it at some point.
I can have a go at that soon, will have to happen after the mad rush to get this other stuff done that led to this issue. BTW it was a |
This old method was checking invariants that were spooky-action-at-a-distance: these invariants have changed since then, so this would panic instead of returning a proper error to the caller.
unreachable!
ClientBuildError
assertion give a descriptive errorClientBuildError
when failing to build, instead of filtering out unexpected errors
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.
Makes sense to me 👍
This old method was checking invariants that were
spooky-action-at-a-distance: these invariants have changed since then,
so this would panic instead of returning a proper error to the caller.
Signed-off-by: [email protected]