javascript/typescript people

getNumberFromCalculation(number a, number b)

better to throw new RangeError when you get a bad number combo that doesn't make sense

or return a RangeError ? (if that's a thing) and then have to check if you return the calculated return number value or an Error every time

Depends on ur structure I suppose but I would usually throw it

Return NaN?

Firstly, document the function's behaviour and return values, including edge cases well using jsdoc. A good choice if you want to conform to things already done in JS in regards to math, return NaN.

@Ranchonyx @horus why do u guys want to return NaN when it’s a RangeError?

It seems like a NaN is not appropriate for this use case - really only if the parameter is in fact NaN it would make sense.

@chonky-quiche Since I'm unsure of what exactly the function does, given, a and b might not even declare a range of numbers, I found it appropriate to return NaN.

If they indeed do declare such a range I would fully agree with you.

I'd rather say that in this case, it's prime for an IllegalArgumentExcrption.

This is not a mathematically nonsensical operation (math-derived exceptions). It's a bad call exception. Make sure to convey it's a bad call (throw) and provide the reason why (precondition).

People who return "sentry" values (which often times can be valid values also) deserve their own place in hell.

If your preconditions are not met, throwing is the only sensible thing.

@chonky-quiche For me, intuitivly NaN is the proper result of a mathematical function called with operands which it isn't defined for. But i just consulted the docs and now i think a RangeError would be apropriate as well (thrown, not returned!).

@CoreFusionX what is a sentry value

@chonky-quiche A value which would indicate something is wrong without doing anything about it, e.g. raising an error. NaN, null, etc. could all be returned as "sentry values" to indicate that the expected result either does not exist or can't be obtained. For example, if you're reading a CSV and some data can't be parsed, it's usually desired to replace it with sentry values rather than throwing an error, since you probably still want to get the rest of the data.

@rewriteitin-c looks like you managed to get Go like error handling in C++ very interesting.

@hitko interesting - never heard them called that way

Your question is really... A tad too unspecific.

NaN isn't just a value.

NaN has a meaning, a specific behaviour like null and stems from floating point arithmetic.

https://developer.mozilla.org/en-US...

I'd rather not return it for simple mathematical operations not involving floating point arithmetic...

"Bad number combo".

So you have let's say two integers, one should be usually between 1 and 20… the other between 1 and 1000.

Let's say these are the expected values.

Then an exception is completely appropriate.

A Range Error would be exactly what you wanna do.

Now... @hitko made an interesting case. Though we now have a problem. Sentry return values are always a source of fun. The kind of fun you don't want.

An exception could be catched. That's the whole point of it. The callee gets to decide wether the error is a grave one and they should terminate or wether its okay to go on.

The callee. Not the function. Important distinction.

A sentry value defines inside the function an error value. The special meaning of the error value has to be conveyed "manually" - as in it's the devs job to recognize that e.g. NaN was used here not as a NaN resulting out of a floating point arithmetic error, but rather because the dev of the function made it an "oops not the input we expected" kind of thing.

If that sounds eerie when you read it... Yeah. Cause it is eerie.
Using an sentry value is seldomly a good idea, especially if the sentry value has a specific meaning and you're entirely redefining that meaning to fit your own needs.

Cause now everyone who uses that function has to be aware of your little shenanigan - and when they are not aware of it, they might be getting a nice migraine trying to figure out why an integer operation yielded an floating point error.

Exceptions were made for that reason. E.g. in @hitko place one could just catch the exception and the callee decides how to handle it.

@IntrusionCM stop being a redditor lmfao

@IntrusionCM i didn't knew, that NaN has as such a specific meaning. I always thought of it as "an undefined but, still typed as number". So I learned something today!

@chonky-quiche :) nah. I don't use reddit.

@horus

Most importantly about it, the fact that NaN == NaN is always false, despite what intuition might suggest.

This could lead to even more shenanigans if you use NaN as a sentry value and use such a comparison as check instead of Number.isNan or similar.

Depends on the application. Sometimes it’s better to return a default value/approximation if the function will be called a lot, and the results don’t always have to be precise. If you rarely call this function, and you always care about the result, you should throw an error.