-
Notifications
You must be signed in to change notification settings - Fork 85
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
feat: add stacktrace parameter on retry #211
base: master
Are you sure you want to change the base?
Conversation
retry/lib/retry.dart
Outdated
@@ -177,8 +177,8 @@ Future<T> retry<T>( | |||
double randomizationFactor = 0.25, | |||
Duration maxDelay = const Duration(seconds: 30), | |||
int maxAttempts = 8, | |||
FutureOr<bool> Function(Exception)? retryIf, | |||
FutureOr<void> Function(Exception)? onRetry, | |||
FutureOr<bool> Function(Exception, StackTrace)? retryIf, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think users should be allowed to condition the retry on the stacktrace.
if you're doing this something is very wrong. It's probably better to fix the thing that is wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, retryIf should not carry the stackTrace parameter.
Updated.
retry/lib/retry.dart
Outdated
FutureOr<bool> Function(Exception)? retryIf, | ||
FutureOr<void> Function(Exception)? onRetry, | ||
FutureOr<bool> Function(Exception, StackTrace)? retryIf, | ||
FutureOr<void> Function(Exception, StackTrace)? onRetry, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be useful, but is it worth doing a breaking change over this?
Maybe we can make a new optional parameter instead of onRetry
or to complement onRetry
. Like logRetry
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated.
32672d6
to
120c252
Compare
retry/lib/retry.dart
Outdated
Future<T> retry<T>( | ||
FutureOr<T> Function() fn, { | ||
FutureOr<bool> Function(Exception)? retryIf, | ||
FutureOr<void> Function(Exception)? onRetry, | ||
Function? onRetry, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this we loose typing.
It's a valid way to solve this, but how about doing:
FutureOr<void> Function(Exception)? onRetry,
FutureOr<void> Function(Exception, StackTrace)? logRetry,
Is there any reason we can't have both?
We could even do:
@Deprecated('Use `logRetry` instead of `onRetry`')
FutureOr<void> Function(Exception)? onRetry,
FutureOr<void> Function(Exception, StackTrace)? logRetry,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if there is an annotation or comment that'll allow us to hide the parameter from auto-completion :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Deprecated('Use `onRetryFailure` instead of `onRetry`')
FutureOr<void> Function(Exception)? onRetry,
FutureOr<void> Function(Exception, StackTrace)? onRetryFailure,
Thank for review.
Updated.
Do you think 'onRetryFailure' would be a good name for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, isn't logging the only legitimate use-case for onRetry
, hence, logRetry
might be a good name, or retryLog
or???
We could also all it whenRetry
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, we'll have a hard time breaking this API in the future. So I propose not making mistakes.
onRetryFailure
is a bit long, and also implies that it should be called when retrying fails.
We could also call it onError
, but that name is used else where to create an alternative value when an error happens.
I'm open to other ideas than logRetry
, but let's try to keep it short and elegant :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think of these names
- (i)
onFailure
. regardless of whether Exception satisfiesretryIf
, it will be called. - (ii)
onError
. any error on retry, it will be called.
Which one do you think is better?
120c252
to
0c0e20c
Compare
Add stacktrace parameter on retryIf and onRetry function for getting additional information