DEBUG=true flag

[robertkowalski]

Hi Micheal,

thanks for bignumber.js!

.DEBUG=true is quite useful for additional validations before starting to calculate.

Right now its available via debug=true - which sounds more like something that is not supposed to run in prod.

Right now a few validations are run with it (NaN and exponentials afaik). Also, at some point maybe other debug functionalities are added, which makes me worry to use it right away.

Does something speak against a THROW_ON_NAN setting (just an example), maybe additional to the current debug mode?

All the best,
Robert

[MikeMcl]

Apologies for not responding at the time but I left this issue open for consideration.

I don't want to add another setting but perhaps I should have made DEBUG = true throw on NaN, and perhaps Infinity also, in the first place. I also should probably have called it STRICT mode not DEBUG.

[pavanvora]

Hi Michael,

I hope you're doing well.

I wanted to follow up on this discussion regarding theDEBUG mode and the suggestion to rename it to STRICT mode. We're currently using bignumber.js in a cryptocurrency project and recently we encountered a critical issue where NaN wasn't thrown.

As I see it, throwing error for invalid inputs (e.g undefined) passed to BigNumber constructor should ideally be the default behaviour, regardless of the mode.

Any updates or thoughts on this issue would be greatly appreciated.

Lastly, thank you for all the work you’ve put into bignumber.js.

- Pavan

[MikeMcl]

@pavanvora

Hello

I think the idea behind returning BigNumber NaN rather than throwing, was that instead of users having to try catch so much, they can just check if instance.isNaN() if there is a possibility of an invalid input.

Should I now change the API to always throw on invalid input? No, I don't think it's worth it. The demand isn't there.

Similarly with DEBUG mode - which currently makes the constructor throw on invalid input or on numbers with more than 15 sig digs, and makes BigNumber.isBigNumber(x) check x is properly formed as well as that it is a BigNumber - I might as well leave it as it is.

I think it's numbers with more than 15 sig digs becoming BigNumber NaN that probably trips users up the most. I did get rid of that behaviour in my other library, so I could probably be persuaded to do that here as well.

Basically, it someone wants change around this, they would need to do the thinking and come with exactly what changes should be made, and then I will consider their proposals, but I am not going to initiate change here myself.

Thnaks for the feedback.