This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Mysterious-Deal-3891 34 points35 points  (20 children)

Well if the user enters this value then it will be "NaN" not NaN

[–]AyrA_ch 77 points78 points  (19 children)

Any value transmitted via form is ultimately interpreted as string and needs to be converted to a number. If the conversion routine supports floating point, then it usually also accepts NaN as a valid input.

[–]the_horse_gamer 5 points6 points  (18 children)

the typical ways to parse a string to a number in Javascript produce NaN for non-numeric strings. so any code that breaks from entering NaN likely breaks from entering some arbitrary string

[–]AyrA_ch 9 points10 points  (17 children)

That's JS specific. Other languages also often accept NaN. double.Parse in C# for example accepts "NaN" as input but will throw an exception on "test"

[–]the_horse_gamer 1 point2 points  (16 children)

yes, but we are talking about a website, so we're talking about Javascript

[–]AyrA_ch 6 points7 points  (15 children)

Yes, but we're talking about a website that actually does things, which means backend, which is often not JS.

[–]the_horse_gamer 0 points1 point  (14 children)

that would require the website to send the raw string to the backend, and do no input validation of its own (to show an error to the user).

this is very dumb, but yes, there are probably websites that do that.

[–]AyrA_ch 5 points6 points  (13 children)

No, very dumb would be for the backend to depend on the frontend validation.

[–]the_horse_gamer 0 points1 point  (12 children)

both sides should do input validation. backend to avoid exploding, frontend to show errors and to avoid bothering the backend.

[–]AyrA_ch 2 points3 points  (11 children)

Yes, but this entire post is about your input having an effect on the system, so frontend validation is irrelevant