Repository navigation
Rationalise how tool uses stderr.writeln/print/logging #461
Description
The main advantage of the logging mechanism is that it easily hooks into -v / --very-verbose to enable higher levels of logging. Once we have that, I think it makes sense to use the logging infrastructure for all messages just for code consistency, just have fatal errors go to a level that we always print out.
So I think we should go the following route in the tools:
- never use print
- never use stderr.writeln/stdout.writeln
- do all logging using the logging infrastructure
- have four levels of logging:
- fatal errors, which are always output on stderr
- normal messages (primarily warnings or high-important priority messages like "No analyzer warnings"), which are always output on stdout (maybe we can have a -q option to quiet them)
- information that's output to stdout if you enable -v mode
- verbose information that's output to stdout if you enable --very-verbose mode
Activity
abarth commentedon Feb 1, 2016
@devoncarew might have done this already.
devoncarew commentedon Feb 1, 2016
Yeah, this has been done. The current system is:
printError()for any error that should be displayed to the user. In the CLI tool, this will go out on stderr.printStatus()for any normal message to the user. Things likeI'm analyzing...or3 devices available..printTrace()for any logging / trace info that should be displayed when the tool is run in verbose mode.github-actions commentedon Sep 6, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.