Project

General

Profile

Actions
Copy link

Bug #13062

closed

2.4.0-rc1 BigDecimal regression - to_d inconsistent with other numeric classes

Added by jhawthorn (John Hawthorn) almost 8 years ago. Updated over 7 years ago.

Status:
Closed
Assignee:
mrkn (Kenta Murata)
Target version:
-
ruby -v:
2.4.0-rc1
Backport:
2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
[ruby-core:78800]

Description

To solve #10286, BigDecimal() was changed to raise exceptions on invalid input, which is more consistent with the other numeric types.

Unfortunately, String#to_d now also raises errors, which is inconsistent with the other to_* methods (to_i, to_f), which return 0 on error.

Under ruby 2.4.0-rc1:

> require 'bigdecimal'
> require 'bigdecimal/util'
> "invalid".to_d
ArgumentError: invalid value for BigDecimal(): "invalid"
> "invalid".to_i
=> 0
> "invalid".to_f
=> 0.0

Under ruby 2.3.3 or 2.4.0preview3:

> "invalid".to_d
=> #<BigDecimal:55871ca1f808,'0.0',9(9)>
> "invalid".to_i
=> 0
> "invalid".to_f
=> 0.0

There's also a further problem that BigDecimal() still doesn't behave the same as Integer() when given a string with the number at the start:

Under ruby 2.4.0-rc1:

> BigDecimal("2 turtle doves")
=> 0.2e1
> Integer("2 turtle doves")
ArgumentError: invalid value for Integer(): "2 turtle doves"
> Float("2 turtle doves")
ArgumentError: invalid value for Float(): "2 turtle doves"

So BigDecimal is still inconsistent.

Files

fix_13062_string_to_d.patch (1.57 KB) fix_13062_string_to_d.patch Esse (Piotr Szmielew), 12/25/2016 12:16 AM
Actions
Copy link

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0