Inference / typing suboptimal for catchError / onError functions

[vsmenon]

APIs like Future.catchError are typed to take Function:

https://api.dartlang.org/stable/1.24.3/dart-async/Future/catchError.html

as we have no good way to express the type today. The type should be one of:

• (dynamic) -> FutureOr<T>
• (dynamic, StackTrace) -> FutureOr<T>

As we fallback on Function, this also impacts / negates our ability to infer the type of closures passed to catchError or onError - occasionally leading to annoying runtime errors.

@eernstg suggested one potential (but breaking) fix:

We could make an attempt to stop supporting this "one argument or two arguments, you decide" approach:

Future<S> then<S>(FutureOr<S> onValue(T value), {FutureOr<S> Function(Object) onError, FutureOr<S> Function(Object, StackTrace) onErrorAndStackTrace});

The migration would be supported by static analysis: The functions that want the stack trace should now be passed under the name onErrorAndStackTrace and the remaining arguments should be assignable to type FutureOr<S> Function(Object).

The same idea wouldn't fit catchError, but we might even be able to use the same idea:

Future<T> catchError( FutureOr<T> Function(Object) onError, {bool test(Object error)}); Future<T> catchErrorAndStackTrace( FutureOr<T> Function(Object, StackTrace) onErrorWithStackTrace, {bool test(Object error)});