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

Add exception handling to 'ref.refresh()' #3682

Open
snapsl opened this issue Jul 29, 2024 · 6 comments
Open

Add exception handling to 'ref.refresh()' #3682

snapsl opened this issue Jul 29, 2024 · 6 comments
Assignees
Labels
enhancement New feature or request question Further information is requested

Comments

@snapsl
Copy link

snapsl commented Jul 29, 2024

Is your feature request related to a problem? Please describe.
#3651

Describe the solution you'd like
Here is how riverpod currently recomments implementing a pull to refresh.

RefreshIndicator(
   onRefresh: () async => ref.refresh(provider.future),
   child: ...
)

However, this leads to an exception at the UI level if reading the updated value fails. The “ref.refresh()” function should take care of this.

Instead of returning a value, ref.refresh() should be handled similarly to a mutation that is watched by ref.watch(provider) and can be listened to by ref.listen(provider). Therefore, it does not need to return an actual value, but indicate when the operation has finished (see RefreshIndicator.onRefresh).

Options:

  • ref.refresh() should return a Future<void> / void / FutureOr<void>
  • ref.refresh() returns a value? only containing a value if the refresh was successful
  • add bool arg throwOnError to ref.refresh()

Describe alternatives you've considered
Users should implement their own exception handling. But this needs to be explicitly mentioned in the API reference. Also, the examples in the documentation should be updated accordingly.

@rrousselGit
Copy link
Owner

There's nothing wrong with the future throwing IMO. You're not even awaiting it.
That's similar to ref.watch(provider.future)

Why does that matter?

@rrousselGit rrousselGit added question Further information is requested and removed needs triage labels Jul 29, 2024
@snapsl
Copy link
Author

snapsl commented Jul 29, 2024

You're not even awaiting it.

Thanks...

Uncaught exceptions in callbacks are forwarded to the PlatformDispatcher (link). If these are not handled properly, such “errors” are logged for no reason.

@rrousselGit
Copy link
Owner

There is an error in your code afterall. Why would we want to silence it?
If you want to silence it for the sake of error logging, you can do refresh(...)..ignore()

@snapsl
Copy link
Author

snapsl commented Jul 29, 2024

Yes, the error is that the rebuild of the provider failed, e.g. due to a failed network request. This is logged by provider observer or the network service. However, since ref.refresh triggers an exception, there is an additional error at the UI level, but it is not a UI problem.
This might be nitpicky and .ignore() would solve this. However, I think ref.refresh() should handle this out of the box.

@rrousselGit
Copy link
Owner

This isn't up to ref.refresh. If anything, it's up to RefreshIndicator.
You likely want a RefreshIndicator that does not report errors as "uncaught". Because RefreshIndicator explicitly decided to report the error

You could make a wrapper around it:

class MyIndicator extends StatelessWidget {
  Future<void> Function() onRefresh;

  build(ctx) {
    return RefreshIndicator(onRefresh: () => onRefresh()..ignore(), child: child);
  }
}

@snapsl
Copy link
Author

snapsl commented Aug 1, 2024

Hi @rrousselGit, thank you for taking your time and reviewing this feature request. I understand that this is not a critical issue. Maybe some people also rely on refresh to return a value. For me, its usage was always for (async) callbacks.

Feel free to close this.

Some suggestions:

  1. We could update the API reference to mention that refresh can throw exceptions. This was not obvious to me and certainly not to others either.
  2. When implementing mutations, consider adding exception handling to them as they are also frequently used in callbacks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants