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

Pick a more appropriate name for with_error_fn? #11

Closed
wfxr opened this issue Jun 20, 2022 · 4 comments · Fixed by #15
Closed

Pick a more appropriate name for with_error_fn? #11

wfxr opened this issue Jun 20, 2022 · 4 comments · Fixed by #15

Comments

@wfxr
Copy link
Contributor

wfxr commented Jun 20, 2022

@Xuanwo This crate is awesome! I never thought of a retry mechanism that could be implemented in such an elegant way. 👍

However the function name with_error_fn is somewhat ambiguous for me. I cannot guess what it is used for without reading the comments.

How about renaming it to continue_if or break_if (on the contrary), following the naming convention in std::ops::ControlFlow:

let content = fetch
    .retry(ExponentialBackoff::default())
    .continue_if(|e| e.to_string() != "EOF") // continue if error is not "EOF"
    .await?;

v.s.

let content = fetch
    .retry(ExponentialBackoff::default())
    .break_if(|e| e.to_string() == "EOF") // stop retrying when error is "EOF"
    .await?;

Personally I think break_if is a good choice. What do you think of it?

@Xuanwo
Copy link
Owner

Xuanwo commented Jul 4, 2022

Sorry for the late response. This idea is quick and cool.

How about when?

let content = fetch
    .retry(ExponentialBackoff::default())
    .when(|e| e.to_string() == "EOF") // If error is retryable, retry it.
    .await?;

@wfxr
Copy link
Contributor Author

wfxr commented Jul 4, 2022

How about when?

More concise! Can I help with this change?

@Xuanwo
Copy link
Owner

Xuanwo commented Jul 4, 2022

Can I help with this change?

Of course! Welcome, go for this!

Although backon is a 0.0.x version, keeping API compatible is still an excellent choice for our users. Please consider adding a #[deprecate] message for with_error_fn instead of removing it directly.

@wfxr
Copy link
Contributor Author

wfxr commented Jul 4, 2022

Although backon is a 0.0.x version, keeping API compatible is still an excellent choice for our users. Please consider adding a #[deprecate] message for with_error_fn instead of removing it directly.

Good advice, 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 a pull request may close this issue.

2 participants