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

Conversion from WrongType to Error? #1011

Open
couchand opened this issue Mar 30, 2023 · 0 comments
Open

Conversion from WrongType to Error? #1011

couchand opened this issue Mar 30, 2023 · 0 comments

Comments

@couchand
Copy link

I'm working on a type that effectively wraps Client. For the most part we're just returning underlying tokio_postgres errors, so the wrapper's methods all return Result<_, tokio_postgres::Error>. This has been working very well for basic usage, but I'm running into situations where it breaks down. Namely, we want to do additional verification ahead of time.

I am in a situation where I have a postgres_types::WrongType enum value and a parameter or column index, and I'd really like to be able to produce a tokio_postgres::Error value from it to return to the user. I'd love to have outside access to the Error::to_sql and Error::from_sql methods, since they look to do exactly what I want and those errors already represent my error conditions.

I understand you're trying to minimize the API surface of the Error type. However, I'd really like to not have to introduce my own error enum here, since it would basically be replicating what tokio_postgres::Error already has:

pub enum Error {
    Upstream(tokio_postgres::Error),
    ToSql(usize, Box<dyn error::Error + Sync + Send>),
    FromSql(usize, Box<dyn error::Error + Sync + Send>),
    // potentially other variants representing other errors I can't construct
}

// plus a whole lot of boilerplate to make it useful for users

I'd much rather continue using tokio_postgres::Error, since it already has variants representing the error cases I'm working with, and if the user doesn't need to think about an additional error type the API would be much more approachable.

Would you be open to some way of producing Errors in a downstream crate? (Perhaps hidden behind an appropriately-scary feature flag like diesel's i-implement-a-third-party-backend-and-opt-into-breaking-changes?)

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

No branches or pull requests

1 participant