BigDecimal should NEVER throw exceptions!!!

[Tectract]

BigDecimal should not throw errors. Ever. You guys need to wrap the code in a begin...rescue with a return 0 for all "error" cases. Anything that's not a valid number is 0 or null or NaN or whatever, but this little math function should NOT be halting my code by throwing errors back upstream.

'invalid value for BigDecimal()'
NO! What the hell!? Whose idea was it for a math function to kick up exceptions?

[Tectract]

Updated bundler and now I have to go inspect every BigDecimal in my codebase for BREAKING changes!!! Not ok.

[bdewater]

No, it should. BigDecimal("foo") now raises an ArgumentError just like Integer("foo") had always done. If you want invalid input to be coerced to zero, use "foo".to_d just like you would use "foo".to_i.

[Tectract]

disagree. Math functions should not raise exceptions. If Integer raises exceptions, that should be fixed also.

[bdewater]

The ability to raise is very useful when dealing with external input. The old behaviour is coercing to zero from BigDecimal.new meant in our app we had no idea if a zero came from actually valid input or not, requiring a workaround (Float(input)) before passing it to BigDecimal.

The behaviour you need is still there, just find & replace.

[Tectract]

The ability to raise is also insanely annoying when your code continually breaks because every minor library call didn't like your unformatted input, and caused a halt. It's a bug not a feature.

[mrkn]

@Tectract
BigDecimal just follows the behaviors of core numeric classes such as Integer and Float.

If you want to discuss them, you should go to https://bugs.ruby-lang.org/.

By the way,

If Integer raises exceptions, that should be fixed also.

How do you fix this?

1 / 0 #=> ZeroDivisionError (divided by 0)

[mrkn]

@Tectract

Updated bundler and now I have to go inspect every BigDecimal in my codebase for BREAKING changes!!! Not ok.

If you don't want to use the latest bigdecimal, you can specify the old version in your Gemfile.

Thanks.

[sorah]

The ability to raise is very useful when dealing with external input. The old behaviour is coercing to zero from BigDecimal.new meant in our app we had no idea if a zero came from actually valid input or not, requiring a workaround (Float(input)) before passing it to BigDecimal.

Correct.

The ability to raise is also insanely annoying when your code continually breaks because every minor library call didn't like your unformatted input, and caused a halt. It's a bug not a feature.

What if a result is calculated wrong with an invalid input? How are you going to know that is caused by such input? Then how you'll deal with the wrong result, when the input was lost at the timing of notice of the error?

[Tectract]

Should be re-opened. BigDecimal should never throw errors.

What if a result is calculated wrong with an invalid input?

NaN should be output in such a case.

If you don't want to use the latest bigdecimal, you can specify the old version in your Gemfile.

Referring to an old version because a BUG was introduced in the new version is not a solution.

[Tectract]

How do you fix this?
1 / 0 #=> ZeroDivisionError (divided by 0)

NaN or infinity. Simple.

[Tectract]

I request this issue should be re-opened, until this discussion is finalized:

https://bugs.ruby-lang.org/issues/14587

[yuki24]

We are not going to re-open this. Raising an exception is perfectly reasonable in Ruby. Every language has a different paradigm and not respecting the language's design like above is absurd. See how different Golang is from Ruby. It simply doesn't make sense to add the exception me mechanism to Golang, or to remove it from Ruby.