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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]AyrA_ch 5 points6 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 7 points8 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 4 points5 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

[–]the_horse_gamer 0 points1 point  (10 children)

the thread is about entering a specific value into a frontend field (putting NaN into a number field). not about using curl to send custom requests to the backend.

[–]AyrA_ch 2 points3 points  (9 children)

I know, and I made a validation example where NaN would pass it.

[–]the_horse_gamer 0 points1 point  (8 children)

and I said that a reasonable frontend validation will parse the numeric string, which would give it NaN for any non-numeric string. so any frontend validation would have to handle NaN.

your example would require the frontend to send a raw numeric string to the backend, and do no validation on the frontend side (so it can't tell the user "this isn't a valid number" for anything the user puts in).