Analyzer should detect if improperly typed handler passed to Future.catchError.

[stereotype441]

Due to the fact that Future.catchError supports two kinds of callbacks, its callback parameter is typed Function, which means it gets very limited type checking from the analyzer.

Since this is a commonly used core method, it would be nice if the analyzer had some special case logic to type check it. I'm not sure whether it should be a hint or a lint (@bwilkerson, @pq, WDYT?)

Related issues: #35812, #34144, #31939, #35545.

[pq]

My inclination is that this should be a hint and agree it would be high value. 👍

[zanderso]

Is there any update on this? Thanks!

[pq]

Thanks for the nudge @zanderso.

@bwilkerson: any objection to treating this as a hint?

[srawlins]

With null safety, the priority on this is raised. See #44386. I'd like to implement it as a Hint. I think there would be zero false positives.

• The function must accept either one Object param, or one Object and one StackTrace param.
• The function must return Future<T>.

[lrhn]

If this can be extended to other Function-typed error handlers, then that would be nice. Not nearly as critical, though.

Most of the remaining error handlers are void-returning functions, so you'd only be checking that they accept (Object) or (Object, StackTrace), but that's still relevant for some situations. For example stream.handleError((FooException e) { ... }) where you know that the exception will be a FooException, but the function must still accept Object.
Or even stream.handleError((FooException e) => ..., test:(o) => o is FooException).

[bwilkerson]

Sorry, I missed seeing this earlier. I agree that this should be a hint.

[srawlins]

If this can be extended to other Function-typed error handlers, then that would be nice. Not nearly as critical, though.

+1