client: Include version info and interface name in BindError
#682
Conversation
| /// If the lower bound of the `version` is less than the version advertised by the server, then | ||
| /// If the lower bound of the `version` is greater than the version advertised by the server, then | ||
| /// [`BindError::UnsupportedVersion`] is returned. |
There was a problem hiding this comment.
What I assume happened here is that let version in the code is rebound to what is found in the global registry (i.e. the version that is available), while "the lower bound of the version" is rebound to version_start.
When `BindError` is returned (and bubbled up by callers) it is no longer clear what interface or version was requested (nor what is the highest this server might be able to provide), leaving users to wonder what the context for the error is. Add this information to the object to elaborate in error messages and allow callers to read the values after the fact.
MarijnS95
force-pushed
the
binderror-context
branch
from
504af0a
to
068d582
Compare
|
Yup, I was using this on top of |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #682 +/- ##
==========================================
- Coverage 73.00% 72.97% -0.03%
==========================================
Files 48 48
Lines 7826 7826
==========================================
- Hits 5713 5711 -2
- Misses 2113 2115 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
When
BindErroris returned (and bubbled up by callers) it is no longer clear what interface or version was requested (nor what is the highest this server might be able to provide), leaving users to wonder what the context for the error is.Add this information to the object to elaborate in error messages and allow callers to read the values after the fact.
This supersedes #671 by also including the requested version and interface name (in addition to the available version), and a documtation fix.
Note that all of this might be considered redundant as the caller typically knows these values (they passed them as function arguments), and it would be up to them to re-wrap the error with this info as context? Is there a policy for this?