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

185 fix err handle and add unit test of string and number #189

Merged
merged 2 commits into from
Dec 5, 2022

Conversation

k4n4ry
Copy link
Contributor

@k4n4ry k4n4ry commented Dec 4, 2022

fix #185

@coveralls
Copy link
Collaborator

coveralls commented Dec 4, 2022

Coverage Status

Coverage increased (+0.3%) to 92.66% when pulling 64b4b0c on knry0329:feature/add-number-string-test into f7e16e0 on gavv:master.

@k4n4ry k4n4ry changed the title 185 add unit test of string and number 185 fix err handle and add unit test of string and number Dec 4, 2022
@@ -563,7 +563,7 @@ func (s *String) AsNumber(base ...int) *Number {
inum, err = strconv.ParseInt(s.value, base[0], 64)
num = float64(inum)

if err == strconv.ErrRange {
if errors.Is(err, strconv.ErrRange) {
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 suppose errors.Is can handle error properly

Comment on lines +345 to +349
value3 := NewString(reporter, "8000000000000000")
num3 := value3.AsNumber(16)
value3.chain.assertOK(t)
num3.chain.assertOK(t)
assert.Equal(t, float64(9223372036854775808), num3.Raw())
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This test case may not be the expected output.
Converting 8000000000000000 from hexadecimal to decimal will be 9223372036854775808,
but num3.Raw() is 9223372036854776000.
This may be due to rounding by float64.

Copy link
Owner

Choose a reason for hiding this comment

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

Good catch!

I've pushed follow-up commit: 67cdcd4

I've replaced 8000000000000000 with 4000000000000000 (2^62), the value from which float64 starts loosing precision for integers.

I also added precision loss checks to AsNumber, so that it fails if the string is an integer that can not be represented as float64 without loss, and added tests for that.

Copy link
Owner

Choose a reason for hiding this comment

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

I've created a new issue #191 for a more appropriate fix for this problem.

@gavv gavv merged commit 08bdd0c into gavv:master Dec 5, 2022
@gavv
Copy link
Owner

gavv commented Dec 5, 2022

Thanks!!

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.

Improve test coverage of Number and String
3 participants