Oh JavaScript, you silly goose.
-
Ok, but I must admit that I still do not like it. This way you always have to test the results which bloats up the code. First, it's an avoidable error and, assuming it comes to my attention, I will find out why the denominater can become zero and then eliminate the problem once and for all. So what's won by bravely keeping going until the error manifests itself somplace else? You will just have to spend more time tracing it back to its origin and then essentially doing the same work to correct it.
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.But if it didn't do this you would just always have to test the inputs instead to ensure the application doesn't throw an error, which isn't necessarily any better. Besides, it's possible you may not have to test the results anyway, if you aren't relying on them being a number, e.g. in the below code it doesn't matter if b is 0:
if(a / b === 0.25){ ... }
-
No; keeping the application from crashing is the application developer's job, not the language or library developer's job.
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. -
But if it didn't do this you would just always have to test the inputs instead to ensure the application doesn't throw an error, which isn't necessarily any better. Besides, it's possible you may not have to test the results anyway, if you aren't relying on them being a number, e.g. in the below code it doesn't matter if b is 0:
if(a / b === 0.25){ ... }
Benito Aramando wrote:
But if it didn't do this you would just always have to test the inputs instead to ensure the application doesn't throw an error, which isn't necessarily any better.
Let's assume a very common case in C#: A reference is null and an exeption will be thrown if the program tries to use the reference. If this can be corrected, then testing beforehand and performing this correction is the way to go. If not, then what could I possibly accomplish by testing? I simply let the exeption fly, let it end up in some Pokemon exception handler and will get to read about it in the log. After that I will check the conditions that led to the error and will never have to worry about it ever again. Avoidable errors should indeed be avoided, not handled (gracefully or not) or tested. They are like sand in your gears. I want them to come to my attention and getting rid of them once and for all is worth the time and the work.
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. -
Benito Aramando wrote:
But if it didn't do this you would just always have to test the inputs instead to ensure the application doesn't throw an error, which isn't necessarily any better.
Let's assume a very common case in C#: A reference is null and an exeption will be thrown if the program tries to use the reference. If this can be corrected, then testing beforehand and performing this correction is the way to go. If not, then what could I possibly accomplish by testing? I simply let the exeption fly, let it end up in some Pokemon exception handler and will get to read about it in the log. After that I will check the conditions that led to the error and will never have to worry about it ever again. Avoidable errors should indeed be avoided, not handled (gracefully or not) or tested. They are like sand in your gears. I want them to come to my attention and getting rid of them once and for all is worth the time and the work.
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.I should have put my statements the other way around. Your response to the one you quoted is fair enough, but your point is predicated on the assumption that the result of a division by 0 must always represent an error that should have been avoided before that point. This isn't necessarily the case.
-
I should have put my statements the other way around. Your response to the one you quoted is fair enough, but your point is predicated on the assumption that the result of a division by 0 must always represent an error that should have been avoided before that point. This isn't necessarily the case.
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. -
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.
