-
Notifications
You must be signed in to change notification settings - Fork 45
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
Use a more fitting error type #64
Comments
Is this one already taken? |
I believe @ffuugoo is preparing work on this. We're having some internal conversions on what the final error type would look like. |
I think the most elegant way to address it is to use |
I don't see the great benefit of thiserror compared to a plain declarative macro, and the latter certainly compiles faster. Btw. it's often a good idea to have specific error types for classes of operations, or even per method, so you don't get variants that don't ever exist. Makes matching easier. |
I meant that |
Currently this crate uses
anyhow
, which is usually meant for applications, not libraries. This makes it very hard to match on an error, because the error is essentially opaque. As far as I can see, we mostly return ´tonic::Status`, but there may be some APIs that also can return other errors.The classic way of dealing with this is create a newtype that wraps Status, has a
From<Status>
impl and allows basically the same functionality (especially matching onCode
). We could also create anenum
instead, but I should note that this will either make the implementation, the user interface or both needlessly complex. If we have API calls that can return other errors, either have them return their own specific error type or convert whatever error we get to our predefined error type internally.Another way would be to make the error type opaque, but that has the downside of making it harder for users to implement
From<QdrantError>
for their own error types, essentially requiring aBox
or other indirection.The text was updated successfully, but these errors were encountered: