Repository navigation
Update flutter_command.dart getter methods for command line options #101595
Description
Use case
Currently this 4 methods (https://github.com/flutter/flutter/blob/flutter-2.13-candidate.0/packages/flutter_tools/lib/src/runner/flutter_command.dart#L1505) checks if argResults is null and it defaults to dummy values if so. They make an assumption that the argument passed to them is valid therefore if the key is not found this methods raise an ArgumentError
/// Gets the parsed command-line option named [name] as a bool.
bool boolArg(String name) => argResults?[name] as bool? ?? false;
/// Gets the parsed command-line option named [name] as a String.
String? stringArg(String name) => argResults?[name] as String?;
/// Gets the parsed command-line option named [name] as an int.
int? intArg(String name) => argResults?[name] as int?;
/// Gets the parsed command-line option named [name] as List<String>.
List<String> stringsArg(String name) => argResults?[name] as List<String>? ?? <String>[];
Proposal
Make new boolArg and stringArg functions to return bool? and List? respectively and for stringArg and intArg to check if the given argument is valid to avoid the ArgumentError; then start incrementally using the new functions in all the places needed; the caller should handle what default value to use if a null is returned.
bool? boolArgSafe(String name) {
if (argResult == null) {
return null
} else {
bool? result;
if (argParser.options.containsKey(name)) {
result = argResults[name] as bool? ?? false
}
return result;
}
}
// eg: argResults = {"key1": bool}
void myCaller(){
bool? key1 = boolArg("key1")
bool? key2 = boolArg("key2")
if (key1 == null || key2== null){
print("Missing params")
}
...
}
- rename current functions
fnNametofnNameDeprecated - make new function handling nulls
bool? boolArg - make new function handling nulls
String? stringArg - make new function handling nulls
int? intArg - migrate
boolArgDeprecatedtoboolArg - migrate
stringArgDeprecatedtostringArg - migrate
intArgDeprecatedtointArg - rename
stringsArgDeprecatedtostringsArg
Activity
christopherfujino commentedon Apr 11, 2022
Interesting that
stringArgandintArgare nullable, but the other aren't. Given this, I feel like it would be desirable to to pick a consistent API, whether it's to have two versions of each or a single for each.I think this could just be:
christopherfujino commentedon Apr 11, 2022
In thinking more, I guess it makes sense that
stringsArgwould have a default value, because it's pretty obvious what the default should be (empty list).That makes the only outlier
boolArg(). Can I suggest that we machine-rename theboolArgfunction and all of its uses toboolArgDeprecated, and then create a new nullable version namedboolArg(). All new invocations must usebool? boolArg(), and we would incrementally migrate all existing invocations ofboolArgDeprecated()->boolArg().Jasguerrero commentedon Apr 11, 2022
Agree. I like that approach better, and for the
stringsArgupdate the function to handle theargResults[name]being empty (return an empty list too if this happens) and avoid the ArgumentError exception; we can follow the same approach as theboolArgDeprecated()christopherfujino commentedon Apr 11, 2022
Not sure what you mean here. Doesn't it already handle
argResults[name]being null with the fallthrough at the end?Jasguerrero commentedon Apr 11, 2022
No. The fallthrough dosen't go throw the end, it fails in this part
argResults?[name]because argResults is not null butargResults[name]does not exist and therefore theArgumentErroris raised; here is an stack trace as an examplechristopherfujino commentedon Apr 11, 2022
Ohh, I see what you mean. So
intArgandstringArgare not safe either. We should probably migrate all four of these to methods that check if the key was parsed first, and only if so read the value.Jasguerrero commentedon Apr 11, 2022
They are not. So yeah those need to be migrated as well.
christopherfujino commentedon Apr 11, 2022
Sounds good to me, I think we need four new methods, but to ensure we don't add new invocations to the old methods, rename the existing ones first, and then have the new methods that check if the name was parsed first use the existing method names.
stringArg -> stringArgDeprecated refactor flutter#101595
new stringArg function safe flutter#101595
add tests for new function flutter#101595
jmagman commentedon Mar 8, 2023
intArgunused, removed in #122124matanlurey commentedon Jul 11, 2025
We don't plan to make these changes, or will when they are useful versus a holistic cleanup.
github-actions commentedon Jul 25, 2025
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.