Skip to content

Rationalise how tool uses stderr.writeln/print/logging #461

@Hixie

Description

@Hixie

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

Metadata

Metadata

Assignees

Labels

c: contributor-productivityTeam-specific productivity, code health, technical debt.toolAffects the "flutter" command-line tool. See also t: labels.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions