Skip to content
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

Make the battery status always valid on windows #2288

Closed
wants to merge 1 commit into from

Conversation

rrrapha
Copy link
Contributor

@rrrapha rrrapha commented Sep 18, 2019

This change was once suggested by @uklotzde.

@@ -44,6 +40,10 @@ void BatteryWindows::read() {
if (seconds_left >= 0) {
m_iMinutesLeft = seconds_left / 60;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't remember that I ever suggested such a change ;)

m_iMinutesLeft is not always set in this branch. Initializing both m_chargingState and m_iMinutesLeft with UNKNOWN helps to guarantee a consistent state upon exit.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting m_dPercentage to 0.0 should not even be required if m_chargingState = Battery::UNKNOWN? Initializing it with NaN instead of 0.0 would emphasize this.

Considering the complexity of the various branches I would recommend to keep the initialization to invalid/unknown values at the beginning of the function.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't remember that I ever suggested such a change ;)

Sorry, it wasn't you, @daschuer requested this change in #2160:

"Can you move that into the else branch below. This way the member value is always valid."

Feel free to close this pull request if you think the change is unnecessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

m_iMinutesLeft is not always set in this branch. Initializing both m_chargingState and m_iMinutesLeft with UNKNOWN helps to guarantee a consistent state upon exit.

I have fixed the not always set m_iMinutesLeft and m_chargingState.
Not initializing them with UNKNOWN is the point of this pull request.
(Setting m_chargingState to UNKNOWN for a short period of time, if it is actually known may be suboptimal)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No interception possible, the unknown value will never become visible. Control flows could be simplified if only known and defined values need to be written. And it is safer if you could exit the function at any time while still leaving the object in a valid state.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No interception possible

Yes, there is no interception possible. The unknown value could only become visible in a crash dump or debug session. Not sure if it really matters..

@uklotzde
Copy link
Contributor

I'm not convinced that the code gets easier to follow by using deeply nested if blocks. Safely initializing the members with invalid/unknown default values and returning as soon as possible when you are not able to read the required values is simpler and more robust.

@rrrapha
Copy link
Contributor Author

rrrapha commented Sep 19, 2019

I'm not convinced that the code gets easier to follow by using deeply nested if blocks.

If we agree that the class members do not have to be valid at any time, this pull request can be closed. (@daschuer please reopen if you think this is wrong)

@rrrapha rrrapha closed this Sep 19, 2019
@rrrapha rrrapha deleted the batterywindows branch September 20, 2019 10:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants