Bot closed the previous issue ( #3480 ), just reminding problem still exists
go version)?go version go1.9.2 linux/amd64
It does with go playground
Same as #3480
https://play.golang.org/p/K4xwS7iy4MP
Not throwing serialization errors on basic numeric data types with valid state
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
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/infecma_null - do as standard stays on encoding, decode null to nan and let user worry what to do about itClosing 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.)
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 messstandard 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 stringinf/-inf; with option above woud generate/decode-inf/nan/infecma_null- do as standard stays on encoding, decode null to nan and let user worry what to do about it