|
True.
|
|
|
|
|
Friend: Do you mean your whole life fits on two 3.5 inch floppy disks?
Coder: Well, yes, ... ... ... and also some cache in my bank account 
|
|
|
|
|
The flaw with that comic:
If he's only been coding for 12 years, it's kinda surprising he's used floppies long enough to still remember their storage capacity.
|
|
|
|
|
A european floppy or an african floppy?
|
|
|
|
|
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);
console.log(1 / 0);
var divide = (...args) => args.reduce((a, b) => a / b);
console.log(divide(0, 0));
console.log(divide(1, 0));
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
modified 13-Dec-15 1:20am.
|
|
|
|
|
This way of sweeping all kinds of errors under the rug is one of the many reasons why I will never voluntarily use it for any serious 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 f***ing 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.
|
|
|
|
|
It doesn't just sweep it under the rug. It returns Infinity rather than just crashing. It seems like a much better solution than bringing down the entire system.
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 f***ing 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.
|
|
|
|
|
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  .
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
|
|
|
|
|
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
|
|
|
|
|
Good point.
Jeremy Falcon
|
|
|
|
|
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
|
|
|
|
|
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 f***ing 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.
|
|
|
|
|
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 f***ing 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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
