Oh JavaScript, you silly goose.
-
After years and years of using JavaScript, only now do I find that checking for zero on the denominator when dividing is a complete waste of time since JavaScript handles it gracefully without crashing.
console.log(0 / 0); // returns NaN
console.log(1 / 0); // returns Infinity// let's get fancy
var divide = (...args) => args.reduce((a, b) => a / b);console.log(divide(0, 0)); // still returns NaN
console.log(divide(1, 0)); // still returns Infinity// if I want to save the sucker in a database
var result = divide(42, 0);
saveMeSomehow.result = isNaN(result) || !isFinite(result) ? 0 : result;These young kids these days just don't know how spoiled they are. Note: I don't think the syntax highlighting supports ES6 yet, so yay I broke the Internet.
Jeremy Falcon
.NET does exactly the same thing with floating-point arithmetic. AFAIK, so does Java. The behaviour is required by IEEE-754[^]:
IEEE-754 : Frequently Asked Questions : Why doesn't division by zero (or overflow, or underflow) stop the program or trigger an error?[^]
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
-
.NET does exactly the same thing with floating-point arithmetic. AFAIK, so does Java. The behaviour is required by IEEE-754[^]:
IEEE-754 : Frequently Asked Questions : Why doesn't division by zero (or overflow, or underflow) stop the program or trigger an error?[^]
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
-
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 === 10then whenyequals 0 you probably just want afalseresult, not an unhandled exception. This behaviour means that you only have to put in special-case handling fory === 0if 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
-
Most of the time it is, so if the exception comes and it is not, you know what to do to meet this precondition. The other way around some real errors may go unnoticed for a long time, plus the extra effort for tracing it back to its origin.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.JavaScript still throws errors for a lot of things, but it and many other fourth generation languages (so I've been told) have decided to do something about dividing by zero being worthy of an "error". I happen to agree it's not an error, since infinity is a valid concept.
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 === 10then whenyequals 0 you probably just want afalseresult, not an unhandled exception. This behaviour means that you only have to put in special-case handling fory === 0if 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.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
-
Most of the time it is, so if the exception comes and it is not, you know what to do to meet this precondition. The other way around some real errors may go unnoticed for a long time, plus the extra effort for tracing it back to its origin.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.The thing is that that exception may not appear until your application is live. I don't think Javascript should throw application-crashing runtime errors in order to help you identify conditions in your code that may not even be bugs.
-
After years and years of using JavaScript, only now do I find that checking for zero on the denominator when dividing is a complete waste of time since JavaScript handles it gracefully without crashing.
console.log(0 / 0); // returns NaN
console.log(1 / 0); // returns Infinity// let's get fancy
var divide = (...args) => args.reduce((a, b) => a / b);console.log(divide(0, 0)); // still returns NaN
console.log(divide(1, 0)); // still returns Infinity// if I want to save the sucker in a database
var result = divide(42, 0);
saveMeSomehow.result = isNaN(result) || !isFinite(result) ? 0 : result;These young kids these days just don't know how spoiled they are. Note: I don't think the syntax highlighting supports ES6 yet, so yay I broke the Internet.
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.
-
After years and years of using JavaScript, only now do I find that checking for zero on the denominator when dividing is a complete waste of time since JavaScript handles it gracefully without crashing.
console.log(0 / 0); // returns NaN
console.log(1 / 0); // returns Infinity// let's get fancy
var divide = (...args) => args.reduce((a, b) => a / b);console.log(divide(0, 0)); // still returns NaN
console.log(divide(1, 0)); // still returns Infinity// if I want to save the sucker in a database
var result = divide(42, 0);
saveMeSomehow.result = isNaN(result) || !isFinite(result) ? 0 : result;These young kids these days just don't know how spoiled they are. Note: I don't think the syntax highlighting supports ES6 yet, so yay I broke the Internet.
Jeremy Falcon
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.
-
After years and years of using JavaScript, only now do I find that checking for zero on the denominator when dividing is a complete waste of time since JavaScript handles it gracefully without crashing.
console.log(0 / 0); // returns NaN
console.log(1 / 0); // returns Infinity// let's get fancy
var divide = (...args) => args.reduce((a, b) => a / b);console.log(divide(0, 0)); // still returns NaN
console.log(divide(1, 0)); // still returns Infinity// if I want to save the sucker in a database
var result = divide(42, 0);
saveMeSomehow.result = isNaN(result) || !isFinite(result) ? 0 : result;These young kids these days just don't know how spoiled they are. Note: I don't think the syntax highlighting supports ES6 yet, so yay I broke the Internet.
Jeremy Falcon
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.
-
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.
