Correct FormatException
when parsing Invariant-locale numbers in user's locale
#125
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.
Several people are reporting that WinNUT is crashing when it attempts to parse the
ups.realpower.nominal
variable that's returned from the server.This PR refactors some code in the
UPS_Device
class related to variable retrieval and parsing. Special precaution is added around the power variable parsing and calculation, and correct variable types are now used throughout (Integer
->Double
.) In addition, I now understand that the.Parse()
method strictly adheres to the executing machine's locale and will throw the relevant exception should it encounter any number beyond the current locale, unless a locale is manually specified. I've updated howUPS_Device
refers to the Invariant culture, which is now used throughout the class. This should completely resolveFormatException
s revolving around power variable parsing.However, this fix points to a greater need for parser and variable handling improvements. Specifically, UPS variables and requests should be represented by individual objects with appropriate metadata attached. This will allow for better state control and error handling by the client. Consider prioritizing migrating WinNUT to the NUTDotNet library.