[camera][google_fonts] Fixes future warning for awaiting Future returns in async bodies inside try blocks

[FMorschel]

This is merely an analyzer change to avoid the bug explained at:

• Linter rule to prevent returning futures from the try block dart-lang/sdk#62555.

This will allow the development of a warning about these situations so we can avoid this bug in the future.

I'm not entirely sure about the version change. This is definitely not working as the author(s) expected (as described on the issue linked above), but I'm not sure how urgent this needs to be published, so I'll leave it up to the reviewers. Same about tests (which I'm not sure exactly where to add them) and CHANGELOGs.

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under¹.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩² ↩³

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

[gemini-code-assist]

Code Review

This pull request adds the await keyword to Future-returning calls within try blocks in async functions across the camera and google_fonts packages. This ensures that exceptions from these asynchronous operations are caught by the surrounding try-catch blocks, which fixes a potential error handling issue. The changes are consistent across all modified files. The pull request description notes that these are bug fixes; based on the repository's contribution guidelines, it would be beneficial to also include corresponding updates to CHANGELOG.md, version bumps in pubspec.yaml, and tests to cover these fixes.

[stuartmorgan-g]

test-exempt: unblocks future analyzer update

[stuartmorgan-g]

I'm not sure how urgent this needs to be published

That's not the bar for our packages, the bar is as documented on the linked page:

Any change that needs to be published in order to take effect must update the version in pubspec.yaml.

This is changing production code's behavior, so by definition needs to be published to take effect.

[FMorschel]

I see. I'm still not entirely sure whether example projects fall into this "to take effect" (since users who look there on pub won't necessarily see the new version). From your phrase below, I only need to add that for production code, then. That would still keep the two projects I added the [] on the issue title. I'm just confirming for the example ones.

Besides the example changes I've still edited:

• packages/camera/camera/lib/src/camera_controller.dart
• packages/google_fonts/lib/src/google_fonts_base.dart

[stuartmorgan-g]

example/lib/main.dart is published to pub.dev (as the Example tab), so does not fall under the "PRs that only affect unpublished parts of example apps" exemption for requiring a version change.