-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Verify type of onError callbacks eagerly #41313
Comments
@lrhn Looking at the implementation of |
Not intentional. So, we should probably do the type testing always, and then only call the |
The I'll add an early check for |
flutter/flutter#81492 looks like caused by insufficient eager checks of return type of an error callback. |
… the wrong type. Bug: #44386, #41313 Change-Id: I87b10c3cd03475f4cd80b7a7c5cba6a558167748 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175062 Reviewed-by: Nate Bosch <nbosch@google.com> Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
I've tried adding eager checking of the return type of the Problems include:
It's likely to be significantly breaking to make a strong up-front requirement on the return type of a function in a position which gets no type inference, and which has so far been more permissive. I'd propose to change the API to require a (We already have the |
Currently, certain core library methods such as
Future.then
takeFunction onError
callback.They do not actually verify the type of the
onError
callback function until it is called.As this is often used for error handling and errors are rare, it could be easily unnoticed that
onError
callback has a wrong type, which may cause flaky, hard to reproduce and hard to diagnose bugs.Consider the following example:
In this example
onError
callback has 3 arguments which is not noticed until the actual error happens. When it happens, it fails in the following way:This stack trace has zero information about the origin of the error. This stack trace doesn't even mention any user code.
I think we can improve usability of those
onError
callbacks by verifying their type eagerly when they are passed to the core library (e.g. on entry intoFuture.then
).This problem becomes even more severe with NNBD.
Previously, the following code was correct:
It compiles and runs fine in weak mode.
However, in strong mode (with
--null-safety
) this example fails withAgain, this stack trace doesn't mention the source of the problem and it is hard to track it down to a particular place in the code where the problem occurs (the fix would be to change
.then
to.then<void>
so that future could hold return values of bothonValue
andonError
)./cc @lrhn @leafpetersen @munificent @liamappelbe
The text was updated successfully, but these errors were encountered: