3

I'm doing some math in Node.js, and I've run into some situations in which a calculation that I would expect to give an error, such as division by 0 and the logarithm of 0, does not do so.

I've read the documentation and some other Q/As, and I understand that returning things like Infinity and -Infinity is normal behavior in Javascript. I'm not arguing for/against this.

I'm wondering, however, if there's a clever way to make JavaScript give me an error instead of continuing the calculations when this happens. The biggest issue is sometimes, an Infinity or -Infinity will get generated in the middle of a long and complex calculation, and that number will continue to be used, and eventually the overall calculation will simply return a normal number which is simply wrong. It's difficult to debug because we have no way of knowing right off the bat where the error happened, since no error is getting thrown and Infinity is an acceptable number in JS.


While the answer to Best way to prevent/handle divide by 0 in javascript provides an answer for specific, known cases where this might occur, I am seeking a catch-all solution for detecting when this might occur, rather than hunt down every case where it might occur or discover each case as I go.

Community
  • 1
  • 1
  • AFIK, there is no option to achieve that behavior, except explicitly checking if result is not an infinity. – qzb May 20 '16 at 21:00
  • Possible duplicate of [Best way to prevent/handle divide by 0 in javascript](http://stackoverflow.com/questions/8072323/best-way-to-prevent-handle-divide-by-0-in-javascript) – Michał Perłakowski May 20 '16 at 21:01
  • @Gothdo I saw that before and addressed it in edit. –  May 20 '16 at 21:05
  • @GeorgePompidou After this edit, this question is rather too broad. – Michał Perłakowski May 20 '16 at 21:07
  • @Gothdo I don't think so. I think it'd be too narrow to just ask how to address division. The issue is with JS giving unexpected results in math and that's what I'm asking about--if it's fixable. –  May 20 '16 at 21:08
  • I suppose I'm looking for some way to disable Infinity or to modify operators/functions, or maybe just a list of math assumptions that the JS makes which aren't agreed upon by the math community... –  May 20 '16 at 21:13
  • I don't have an answer - just curious if there is a way to monitor javascript to see its calculations / partial calculations and log them somewhere. Or, see if there is a javascript math library that meets your needs. – yas May 20 '16 at 21:25

2 Answers2

0

You can for example make a function divide that throws error if the result if the division is Infinity:

const divide = function(dividend, divisor) {
  const result = dividend / divisor
  if (Math.abs(result) === Infinity) {
    throw new Error("Division by zero")
  }
  return result
}

Then in calculations, instead of using the division operator, use that function:

const fourDividedByTwo = divide(4, 2) // gives 2
const oneDividedByZero = divide(1, 0) // throws error
Michał Perłakowski
  • 88,409
  • 26
  • 156
  • 177
  • Yeah, we considered that and it would work, to simply replace divisions by this function. Then we'd have to do it for log too, and who knows what else in the future. Do we know which math operations in JS produce strange results? –  May 20 '16 at 21:07
  • You could just throw the error before doing any calculation eg if (divisor ==0 ) throw new Error ("division by zero") – Jon Ashdown May 20 '16 at 21:08
0

The short answer is don't use javascript for any serious math. Javascript is fault-tolerant (which is why it has Infinity, -Infinity, -0, and NaN), but math isn't. Math is supposed to fail when you try impossible things.

As Gothdo has stated, creating custom functions for the behavior would work.

If you're doing math on more complicated objects (such as Points, or Vectors, or Spaces) that can be represented by a JSON object, there's a way to overload the vanilla operators.

http://www.2ality.com/2011/12/fake-operator-overloading.html

full source at

https://github.com/rauschma/op_overload

It's slightly tricky, and it's not really any more practical than just using functions, but it's kinda cool.

John Kossa
  • 459
  • 2
  • 8
  • It's really late, but I'm going to accept this because I agree with the first sentence and think it's the "correct" resolution. –  Sep 02 '16 at 18:35