BigDecimal should NEVER throw exceptions!!! about bigdecimal HOT 12 CLOSED

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

from bigdecimal.

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.

from bigdecimal.

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

from bigdecimal.

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.

from bigdecimal.

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.

from bigdecimal.

@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)

from bigdecimal.

@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.

from bigdecimal.

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?

from bigdecimal.

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.

from bigdecimal.

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

NaN or infinity. Simple.

from bigdecimal.

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

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

from bigdecimal.

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.

from bigdecimal.