Arrow `onError` functions causes type failure

[grouma]

The following will give a type error:

void showError() { ... }

SomeType someMethod(){
     return foo.bar().first.then((blah)=>blah, onError: (error) => showError());
}

This is because showError returns void when SomeType is expected.

To fix one simply needs to do remove the fat arrow:

void showError() { ... }

SomeType someMethod(){
     return foo.bar().first.then((blah)=>blah, onError: (error) { showError();});
}

This is a pain and the void return type of showError should be interpreted as returning null.

[eernstg]

What's the version of the tools where you've seen this behavior? I cannot see any such issue with version 2.0.0-dev.17.0, so maybe it's just an issue until the tools have been updated.

The type annotation for onError is a plain Function, so there is no (non-trivial) type-from-context for the type inference to use when it determines the type of the function literals, so they'd get a return type which is based on the function body, and dynamic arguments: void Function(dynamic). It seems likely that this bottom-up computation refused to use the return type void for the => function in the older version (and for any other return type than void, a => expression of type void is an error).

[eernstg]

Ah, I guess you're seeing a dynamic error (CastError) rather than a compile-time error. So the problem is that your onError is invoked, and it is supposed to return a value of type SomeType (which is a sort of default value that you'll turn to when the regular approach incurs an error). onError is statically typed as Function, but it really must be something like a SomeType Function(Object) or a SomeType Function(Object, StackTrace) (which is not expressible as a single type which is more precise than Function), and the given function literal does not deliver that SomeType value.

When you use (error) { showError();} the returned value is null, which is OK for the expected type SomeValue. Kind of lucky, or at least it's not obvious which role that null is playing. ;-)

So the underlying problem is actually old and well-known: We can't express the type FutureOr<S> Function(Object) | FutureOr<S> Function(Object, StackTrace) where S is the type argument of then, and that causes useless inference and checking.

[eernstg]

Note that this issue is similar to #16004.

[eernstg]

We might consider the following change (might be to much of a migration cost right now, though):

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

Developers would then need to pass onErrorAndStackTrace: when they want the stack trace, and in return everybody would get better inferred types.

[grouma]

Yes this is a runtime error running with 2.0.0-dev.17.0

[leafpetersen]

This is a pain and the void return type of showError should be interpreted as returning null.

This is unfortunately not true in Dart. A function typed to return void can return any type.

[natebosch]

Should we close this in favor of #34144 or do we think it's a more general issue?

[natebosch]

Closing since most of the conversation is happening in #34143