Error kind is private

[m-lima]

On tokio-postgres::error, Kind is a private enum as well as a private field inside ErrorInner.
There is no way of asserting the error except for parsing the string that comes out of the Display implementation for Error

For example:
In both line 455: pub(crate) fn column(column: String)
and line 479: pub(crate) fn row_count()
the errors are created with no cause, only kind. And the only way to extract that information and discern between the two is by comparing the output of the Display implementation.

Am I missing something or not seeing a way to assess the error kind and take action accordingly?

[sfackler]

Could you be more specific about what actions you want to take in response to errors?

[m-lima]

The application is a warp server. When I do query_one and no items are found I get an error back (Kind::RowCount) signaling that no entries were found.
I cannot, however, differentiate this error easily (without parsing the String representation) and giving a sensible response to the client (in this case I wish to return a 404 Not Found)

[sfackler]

I'd just use query_opt instead and avoid having to deal with figuring out which kind of error it is in the first place.

[m-lima]

Thank you

[hn-sl]

I hope this issue reopened. This is not just about query_opt method. There are many cases when application need to take different action on different kind of errors. For example, application could terminate process when error is caused by syntax error but ignore error from closed connection, but currently there is no easy way to differentiate errors when cause is None.

[Ramambahara]

I found myself in the same situation as @hn-sl: we want to differentiate programming errors and connectivity/availability errors:

I.e. I want the program to terminate if it is a programming error (wrong parameter type in a prepared query,query_one or query_opt returned multiple rows, etc). I want to log and continue if it is a connectivity/availability error.

Having access to the kind of en error, or at least having 'is_error_in_query' would help with that.