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.After rereading my orginal post, I can totally see how you'd think I'd no longer validate input. I'd change the text but it's much more fun letting readers be confused.
Jeremy Falcon
-
It doesn't just sweep it under the rug. It returns
Infinityrather than just crashing. It seems like a much better solution than bringing down the entire system.Jeremy Falcon
No; keeping the application from crashing is the application developer's job, not the language or library developer's job.
-
Oh I totally agree with you on those points. I'm a very defensive programmer so I'd always validate my inputs. To the point my coworkers think I'm nuts for being so verbose. I've been doing some hardcore JS development in the past couple years. I'm just delighted to know that this won't crash the system anymore, which is a step in the right direction. I'll always validate my inputs. It's what Jesus would do.
Jeremy Falcon
Jeremy Falcon wrote:
I'm a very defensive programmer so I'd always validate my inputs
And you wonder why you are just now finding out the divide by zero handling in JS :laugh: .
Never underestimate the power of human stupidity RAH
-
Jeremy Falcon wrote:
I'm a very defensive programmer so I'd always validate my inputs
And you wonder why you are just now finding out the divide by zero handling in JS :laugh: .
Never underestimate the power of human stupidity RAH
Are you back in Oz over Christmas. If so we better catch up for a beer.
Michael Martin Australia "I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash One Fine Saturday. 24/04/2004
-
It doesn't just sweep it under the rug. It returns
Infinityrather than just crashing. It seems like a much better solution than bringing down the entire system.Jeremy Falcon
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
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
Are you back in Oz over Christmas. If so we better catch up for a beer.
Michael Martin Australia "I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash One Fine Saturday. 24/04/2004
Cambodia, going to see the beaches there. Oz is only in cairns these days, very rarely get to Sydney.
Never underestimate the power of human stupidity RAH
-
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
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
That's just example code man, cut me some slack. It's Christmas!
Jeremy Falcon
-
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
-
Jeremy Falcon wrote:
I'm a very defensive programmer so I'd always validate my inputs
And you wonder why you are just now finding out the divide by zero handling in JS :laugh: .
Never underestimate the power of human stupidity RAH
Good point.
Jeremy Falcon
-
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.
-
I don't do any of that Web crap; I do real software development.
Would you like a lollipop?
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.
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.
-
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
-
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.
-
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
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.
-
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
:beer:
veni bibi saltavi
-
:beer:
veni bibi saltavi
Thanks man! Cheers.
Jeremy Falcon
-
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.
