-
Notifications
You must be signed in to change notification settings - Fork 29.7k
throw ToolExit when --web-port is an integer outside the valid TCP port range
#123269
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
throw ToolExit when --web-port is an integer outside the valid TCP port range
#123269
Conversation
ToolExit when --web-port is an integer outside the valid TCP port range
christopherfujino
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM thanks!
The error messages now originate in ResidentWebRunner, which is conceptually isolated from the CLI. While this makes the error message slightly use useful for the --web-port case, this makes it less likely for the log messages to diverge from the actual port selection logic.
|
@christopherfujino re-requesting review because of minor changes in messages and test code |
| Received a non-integer value for port: ${debuggingOptions.port} | ||
| A randomly-chosen available port will be used instead. | ||
| '''); | ||
| return globals.os.findFreePort(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice
|
|
||
| try { | ||
| return await asyncGuard(() async { | ||
| Future<int> getPort() async { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to be a local function, since it's only invoked once? Can we just inline this code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't need to be a (local) function, but I don't think a function needs to be called more than once to justify its existence. In this case, I went with a function to
- provide a clear start and end to port selection logic,
- limit the scope of port selection logic, making it more clear that it doesn't interact with any other code within the
asyncGuardcallback, and - make it easier for first-time readers of the
runmethod by moving the low-level details of port selection out of the way (you can fold/hidegetPortand still understand whatrundoes)
amongst other things.
christopherfujino
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit question about inlining getPort, but otherwise LGTM
…valid TCP port range (flutter/flutter#123269)
…valid TCP port range (flutter/flutter#123269)
…valid TCP port range (flutter/flutter#123269)
…valid TCP port range (flutter/flutter#123269)
…valid TCP port range (flutter/flutter#123269)
…valid TCP port range (flutter/flutter#123269)
Fixes #123147.
Interestingly, arguing a non-integer value (
asdfor123.45) does not result in aToolExitor crash. Instead, we default to null and a randomly-selected open port is used. However, this behavior seems consistent and intentional across different*portoptions across the tool, so I left it alone.Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.