Go: encoding/json: unsupported value: NaN

Created on 4 Jun 2018  ·  4Comments  ·  Source: golang/go

Bot closed the previous issue ( #3480 ), just reminding problem still exists

What version of Go are you using (go version)?

go version go1.9.2 linux/amd64

Does this issue reproduce with the latest release?

It does with go playground

What did you do?

Same as #3480

https://play.golang.org/p/K4xwS7iy4MP

What did you expect to see?

Not throwing serialization errors on basic numeric data types with valid state

What did you see instead?

json: unsupported value: NaN

Which is by the way very uninformative and badly written error message as it doesn't show which key showed that error which just makes hunting the source of NaN utter pain in arse

FrozenDueToAge

Most helpful comment

@mvdan yes I did, and I'm aware that it is pretty messy issue, but IMO just having to deal with NaN being either NaN, inf+ or inf- is better than having ser/des of one document fail because of single (and, currently, hard to find) NaN.

From my experience with other libs in other languages most of them just chose to break strict adherence to JSON buggy mess standard in favour of preserving inf/nan via string representation.

And currently Go is also breaking the standard, just in other way, err'ing out when it should just return string "null", and err'ing out on ingestion with no option to opt out.

Maybe adding additional struct options would help? Like:

  • nan_as_null - treat string "null" as nan; serialize NaN to "null", err out on inf+/inf-
  • nan_as_string - treat string "nan" (and case variations) as nan; serialize NaN to "nan", err out on inf+/inf-
  • inf_as_string - stringify/accept string inf/-inf; with option above woud generate/decode -inf/nan/inf
  • ecma_null - do as standard stays on encoding, decode null to nan and let user worry what to do about it

All 4 comments

This has come up in the past; have you read this thread? https://github.com/golang/go/issues/3480

Also, if you'd like the error to be better, I'd file a separate issue. There have been similar ones in the past, such as https://github.com/golang/go/issues/6716 and https://github.com/golang/go/issues/11858.

@mvdan yes I did, and I'm aware that it is pretty messy issue, but IMO just having to deal with NaN being either NaN, inf+ or inf- is better than having ser/des of one document fail because of single (and, currently, hard to find) NaN.

From my experience with other libs in other languages most of them just chose to break strict adherence to JSON buggy mess standard in favour of preserving inf/nan via string representation.

And currently Go is also breaking the standard, just in other way, err'ing out when it should just return string "null", and err'ing out on ingestion with no option to opt out.

Maybe adding additional struct options would help? Like:

  • nan_as_null - treat string "null" as nan; serialize NaN to "null", err out on inf+/inf-
  • nan_as_string - treat string "nan" (and case variations) as nan; serialize NaN to "nan", err out on inf+/inf-
  • inf_as_string - stringify/accept string inf/-inf; with option above woud generate/decode -inf/nan/inf
  • ecma_null - do as standard stays on encoding, decode null to nan and let user worry what to do about it

Closing this as a duplicate of #3480. You can open a proposal for your suggested change, or you can file a separate issue for improving the error message.

Just create your own custom decoder (and encoder too if nec.)

Was this page helpful?
0 / 5 - 0 ratings