[reificator]

> Imagine you are debugging a 10000 line function that's suppose to return an int, but instead returns a NaN.

I'm imagining that. It's my first day at a new job cleaning up a legacy codebase, but upon opening up a single 10kloc function written in JS, I realize that I made a terrible mistake and immediately hand in my resignation.

In the meantime, I set a breakpoint at the end of the function, inspect the inline value annotations for NaNs, and trace them back to the start.

Relative to any other debugging task in a 10kloc function, that doesn't sound bad at all. If it's consistently returning NaN, that should take maybe half an hour.

Also, I'd be really surprised if the function was made to return an int, because JS doesn't have integer datatypes.

[crimsonalucard]

Read what I wrote again:

> Sure, I can say all kinds of stuff to make finding this error sound simple but if exceptions were thrown instead of assigning NaNs to some variable life would be easier.

I said this in the parent post and sure enough the reply is exactly inline with what I said was going to happen. I don't hate javascript, but it has its horrible horrible warts.

>Relative to any other debugging task in a 10kloc function, that doesn't sound bad at all. If it's consistently returning NaN, that should take maybe half an hour.

An exception would take a second. An exception would give you the target line of every illegal operation; while a NaN propagates itself like a virus along every arithmetic operation.

Some people find it easy to run a 20 miles, sure but that still doesn't change the fact that cars are much better. Get the analogy? You are running 20 miles and telling me how you don't mind... I'm saying sure, but driving still has a purpose in life.

[reificator]

> I said this in the parent post and sure enough someone who is a fan of javascript had to reply with exactly what I said was going to happen.

Breakpoints are off the table? Seriously? I didn't realizing using a debugger made me a JS fanboy.

Wrapping all of your basic arithmetic in try/catch blocks is completely unreasonable. If you need to check for NaN, check for NaN. Making arithmetic substantially slower in the general case to catch the uncommon cases is exactly the problem NaN was introduced to solve.

[crimsonalucard]

No dude. I'm not saying it's off the table. I'm saying it shouldn't be necessary for a 1/0 illegal operation.

I'm not even saying to wrap your functions in try catches. If your program has a 1/0 operation then obviously you made a mistake somewhere. With javascript you have to hunt that mistake down, with a language like python you get the line number of where that mistake occurred. The exception is there for the entire program to fail so that you can correct your mistake. The language should not allow operations to occur that create these things called NaNs and thus automatically this removes the need to check for NaNs too. That's all I'm saying.

BTW unless you explicitly instantiated a NaN you should rarely ever be checking for NaN's in your code. NaNs represent illegal operations like 1/0, and thus any type of code producing a NaN should be killed. If you check for NaNs in your code that means you are guarding your code from your own bugs.

>I didn't realizing using a debugger made me a JS fanboy.

Yeah that was inappropriate. I apologize for calling you that, unfortunately you still saw it before I edited it out.