|
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.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
