docs: tweak the wording around can_connect() usage #1123
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
can_connect()
is a point-in-time check, and, if used as a guard for interacting with Pebble, introduces a race condition where Pebble was responding at thecan_connect()
time, but is not when the rest of the work is done.We already encourage people to handle errors communicating with Pebble when doing the later work (catching
ConnectionError
), which means that most of the time thecan_connect
call is not providing any value (and incurs a small cost). However, the documentation, particularly the example, encourages this pattern, and this has been copied to many other places (charm sources, docs).This PR adjusts the documentation to be less encouraging of
can_connect()
use as a guard, and changes the example to one where a point-in-time check is wanted (for collecting unit status).