|
No; keeping the application from crashing is the application developer's job, not the language or library developer's job.
|
|
|
|
|
I take you don't do much hardcore JavaScript development. I'd rather check for values than have the entire web page stop working with no way to recover because the engine went bye bye.
Jeremy Falcon
|
|
|
|
|
I don't do any of that Web crap; I do real software development.
|
|
|
|
|
Would you like a lollipop?
Jeremy Falcon
|
|
|
|
|
PIEBALDconsult wrote: keeping the application from crashing is the application developer's job
The language shouldn't crash the application unnecessarily, though. The result of a division operation isn't necessarily useless or invalid just because the divisor was 0. If you want to test that x/y === 10 then when y equals 0 you probably just want a false result, not an unhandled exception. This behaviour means that you only have to put in special-case handling for y === 0 if you need it. At the same time, if your use case does require it but you forget to put it in, then you'll probably get the error thrown anyway when you handle the result of the division, rather than the bug being masked.
|
|
|
|
|
Exactly. Having a system crash over an operation like that is not the right solution. In a second and third generation language I can see having a fault since everything has a fault so it's just how it's done, but most certainly not in a fourth generation language.
Jeremy Falcon
|
|
|
|
|
I prefer the application to crash, because if the application doesn't crash in a /0, the programmer needs to know what to do in the case we get a division with 0 without exception, call it division by zero handling.... this then is for Advanced programmers, I can see a lot of code running and doing stuff and crashing some lines after the /0 where the programmer is in a different context, and will have hard time to understand the the issue is a /0 that was not handled 10 lines before...
Then yes I prefer it to blow up in front of my face, a /0 exception is always easier to track. Think on null validations, you had learned to do Null validations because a null crash so ugly that you want to avoid it... I had seen code where a null was not validated (the -> expressions make it so easy to crash due bad null validations) and the code crash 100 lines after that missed validation.
So, I'm not telling is bad or good, just I think it's for advanced programmers, the ones that already learned the price of a division by zero
|
|
|
|
|
Surely an advanced programmer should have little trouble using the stack trace and/or basic debugging tools to trace an error back to a /0 event? Or should be aware of when a 0 input is liable to cause problems and put in special handling for it? After all, even in a statically-typed language you won't get the error until runtime so you need to be aware of the pitfall when coding.
I personally prefer it the way it is, since as a dynamically-typed language JS can handle a /0 without having to throw, and for all the interpreter knows it may be that the result is being handled correctly even when it is not a number, so for JS to throw an error at run time, and potentially in production, when it is by no means a given that an error has occured or will be caused by it, would be bad.
|
|
|
|
|
Until you write stock trading software in Javascript and you end up buying an infinity of shares because somewhere along the line, some value in some database was 0 that you used in a denominator to figure out how many shares to buy. 
Marc
|
|
|
|
|
That's just example code man, cut me some slack. It's Christmas!
Jeremy Falcon
|
|
|
|
|
You didn't know about NaN yet? Or infinity? Or that JS uses elephanting floats all over the place?
It gets better, 1/0 is positive infinity but 1/-0 is negative infinity, even though 0 and -0 compare equal to each other.
|
|
|
|
|
|
harold aptroot wrote: You didn't know about NaN yet? Or infinity? Or that JS uses elephanting floats all over the place?
Everyone knows about NaN, what I didn't know was that I could safely divide by zero without crashing the JavaScript engine / interpreter.
Jeremy Falcon
|
|
|
|
|
That positive 0 and negative 0, of course has nothing to do with JS...
It comes from the IEEE 754 standard, and you can find it in C# implementation too...
Exception handling is very expensive in terms of computer resources, so we already used to validate user input...In this case JS follows to the letter the standard...
https://en.wikipedia.org/wiki/IEEE_floating_point[^]
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I wrote: Or that JS uses elephanting floats all over the place
|
|
|
|
|
Maybe you only need some parentheses like that:
aveMeSomehow.result = ( isNaN(result) || !isFinite(result) ) ? 0 : result;
to get things running. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I'm glad my college math professor doesn't program in JavaScript, he'd have a fit seeing a variable equal to infinity.
Nothing is ever equal to infinity because it isn't a single number. The result of an equation tends to infinity when a certain condition becomes true (I suck at math so I don't think any explanation would make much sense)
In the divide by zero example, the limit of x/n as n tends to zero is infinity.
|
|
|
|
|
![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
veni bibi saltavi
|
|
|
|
|
Thanks man! Cheers.
Jeremy Falcon
|
|
|
|
|
.NET does exactly the same thing with floating-point arithmetic. AFAIK, so does Java.
The behaviour is required by IEEE-754[^]:
The 754 model encourages robust programs. It is intended not only for numerical analysts but also for spreadsheet users, database systems, or even coffee pots. The propagation rules for NaNs and infinities allow inconsequential exceptions to vanish. Similarly, gradual underflow maintains error properties over a precision's range.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I never knew that. Thanks.
Jeremy Falcon
|
|
|
|
|
Here's the thing.
JavaScript's way of handling divide-by-zero is not better or worse than any other. It simply is.
If you have code that should do something specific when a divide-by-zero happens, then you damn well better code it that way. If you are depending on the the language for that specific behavior, then for Pete's sake emulate that behavior when you move to a language that doesn't have the behavior.
JavaScript does not matter. C++ does not matter. Algol does not matter. Only the behavior you want matters. So, know the language, and code accordingly.
|
|
|
|
|
The BASIC that came with the Heathkit computers was way ahead of the game.
It's error message said, "I'm a computer, not God" when you would divide by zero.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
Mathematically, these are the correct answers.
0/n = 0; Since 0 =/= Infinity, 0/0 is Not a Number (NaN)
Lim(1/n)(as n=>0) => infinity; specifically aleph(null). There are multiple infinities and this is just the first of them.
So, regardless of what you think about JavaScript, it handles division by zero properly.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
