|
|
|
|
|
|
by reificator
3094 days ago
|
|
|
> 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. |
|
|
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.