Skip to content

Conversation

hn-sl
Copy link

@hn-sl hn-sl commented Feb 12, 2021

Sometimes application needs to take different action on different kind of errors but there is no easy way to differentiate errors when cause is None (#583).

@sfackler
Copy link
Collaborator

Which kinds of error in particular do you want to handle differently?

@hn-sl
Copy link
Author

hn-sl commented Feb 12, 2021

Which kinds of error in particular do you want to handle differently?

I think in some cases at least Kind::Closed should be handled differently. For example, if query execution is failed by Kind::Close error the application might want to connect to database few seconds later and try the query again. This behaviour is reasonable for many applications because connection lost is not critical error. But currently there is no easy way to check if the failure was caused by Kind::Closed.

Also this can be used to detect connection lost. I know that task from Connection object is terminated as soon as connection is lost, but it would be helpful if connection lost could be detected by error from client method.

@hn-sl
Copy link
Author

hn-sl commented Mar 4, 2021

What do you think about this issue?

@sfackler
Copy link
Collaborator

sfackler commented Mar 5, 2021

I'd be happy to take a PR adding an is_closed() method to Error, but I do not want to expose its internal structure. A direct method will be easier to work with for your use case anyway.

@hn-sl
Copy link
Author

hn-sl commented Mar 28, 2021

Okay I just removed previous commit, synced with latest branch and add is_closed() method. Could you check this update?

@hn-sl hn-sl reopened this Mar 28, 2021
@sfackler sfackler merged commit b0492d4 into rust-postgres:master Mar 29, 2021
@sfackler
Copy link
Collaborator

Thanks!

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

Successfully merging this pull request may close these issues.

2 participants