Dart-code: Dart Code doesn't surface errors that come back from `flutter run` (eg. gradle/android licence failures)

[DanTup]

From @PromoFaux:

Launching lib\main.dart on Pixel XL in debug mode...
Exited (sigterm)

builds fine with flutter run, I'll try again in vsCode

huh. Now it works. I did change some things, Android SDK licenses were not accepted, and needed to add JAVA_HOME so I could even run SDKManager

I only knew about the --accept-licenses tag because intelliJ told me to run it

[DanTup]

Seems like we should be able to give the user some useful info here rather than just quitting quietly.

[DanTup]

@devoncarew @mit-mit Does anyone know how I can easily force a licence check failure? Is there some flag somewhere to say I accepted licences that I can just unset? I've tried reading through the code, but seems like we just catch an existing exception about this and the check isn't actually handled in flutter_tools?

[mit-mit]

Our gradle integration should report back an actionable error:
https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/android/gradle.dart#L132

Perhaps not all of the error is bubbling up to Code?

[DanTup]

@mit-mit That's what I was trying to check, but wasn't sure how best to debug it. But now you mention it, I should be able to just make that method always call throwToolExit locally!

[DanTup]

Looks like we probably don't display stderr. I added this:

printError('* Something went wrong...');
throwToolExit('This is a test failure');

But only the first line appears. Should be any easy fix...

[DanTup]

Actually, I see the same behaviour from flutter run:

Seems like we get an empty newline but no message, so I think maybe flutter run isn't handling throwToolExit correctly? (based on the code, I presume it's expected that user will see the output thrown).

[DanTup]

And here's the code that's assuming throwToolExit output gets to the user:

[mit-mit]

cc @jcollins-g

[DanTup]

The behaviour seems different with flutter run to running the tools directly. Could the crash handling be getting in the way?

PS M:\Coding\Applications\flutter\examples\hello_world> flutter run
Launching lib/main.dart on XT1562 in debug mode...
Initializing gradle...                                       0.8s
Resolving dependencies...                                    1.3s
* Something went wrong...

Oops; flutter has exited unexpectedly.
Sending crash report to Google.
Crash report sent (report ID: 995d8bfbce2ab58c)
Crash report written to M:\Coding\Applications\flutter\examples\hello_world\flutter_04.log;
please let us know at https://github.com/flutter/flutter/issues.

PS M:\Coding\Applications\flutter\examples\hello_world> M:\Apps\Dart\Dart-2.0.0-dev.35.0\bin\dart ..\..\packages\flutter_tools\bin\flutter_tools.dart run
Launching lib/main.dart on XT1562 in debug mode...
Initializing gradle...                                       0.8s
Resolving dependencies...                                    1.3s
* Something went wrong...
This is a test failure

[DanTup]

I guess the question is, should ToolExit exceptions be considered Flutter errors (send them to Google, hide the message) or dumped to the screen for the user (and not reported). I think the error handling code assumes the former but the implementation in the tools the latter.

Things may be slightly different again for flutter run --machine (which is what's being run in the original case here) but fixing the general cli issue might fix that (and if not, at least we'll understand which bit needs to change better).

[jcollins-g]

It seems like a good idea to make the implementation and error handling code consistent regarding the expectation of displaying a message. My first thought is the error handling code should go ahead and display the message itself as that'd be more compact in the implementation, but really as long as it is consistent we shouldn't have this trouble.

[DanTup]

Looks like it's actually coded to work as we want...

So something else must be going wrong so that the error isn't a ToolExit. I'll have to dig into it again.

[DanTup]

Oh, seems like I may have badly reproduced the issue when testing from the command line. You can see if in m screenshot of the code that there's a try/catch around where I added my fake exception. So, I'll go back to testing for flutter run --machine!

[DanTup]

Turns out the error was entirely mine. The error comes back attached to an app.stop event, and I was never looking for it, so it never got output.

I'm not checking all JSON from flutter run for error properties and dumping them to the debug window as errors if they exist.