Bug #14587


math library functions should NOT raise exceptions

Added by Anon92929 (Anon Ymous) about 4 years ago. Updated about 4 years ago.

Target version:


BigDecimal, Integer, Float, none of these should raise exceptions, but they should all fail SILENTLY or return NaN during error cases.


I shouldn't have to go fix every possible way that BigDecimal might throw a breaking change in a thousand places in my codebase. I need math libraries that DON'T BREAK!!!

Related issues 1 (0 open1 closed)

Has duplicate Ruby master - Bug #14588: math library functions should NOT raise exceptionsRejectedActions

Updated by Anon92929 (Anon Ymous) about 4 years ago

BigDecimal maintainers have actually gotten so angry about reports of this bug that they are locking new threads about it.

They WANT my code to break, lol.

Updated by sorah (Sorah Fukumori) about 4 years ago

  • Status changed from Open to Rejected

Rejecting here as we've locked the previous issue at GitHub.

Updated by Anon92929 (Anon Ymous) about 4 years ago

This just represents another way that the mentality of the Ruby programmers seems "sticky", to me.

No implicit conversion of int to string!!! We REFUSE to attempt .to_s automatically, and we INSIST on wasting everyone's time with this silly bug, forever!!!

Oh, you need to cast to a long decimal format? NOPE SORRY your code is broken now because "." is not technically a number, go spend a day trying to figure it out sucker! Your github issue has been CLOSED!!!

Is this how the ruby devs and community intend to win over new young coders? By making a language where everything breaks, there's no logical remediations even attempted, and you can't even trust simple MATH LIBRARIES not to halt your codebase on every version update?

Updated by Anon92929 (Anon Ymous) about 4 years ago

Why has this bug report been rejected?

The bug was rejected at github because I was referred to open a ticket at

The bug was rejectet at because the ticket was closed at github.

No critical thought required! Congratulations.

Updated by shevegen (Robert A. Heiler) about 4 years ago

The explanations and reasons have been stated and given already, Tectract.

See the comments made by bdewater or mrkn or yuki24. It is not a "bug" so
it makes no real sense to claim that there is one when there is not.

Actions #6

Updated by nobu (Nobuyoshi Nakada) about 4 years ago

  • Has duplicate Bug #14588: math library functions should NOT raise exceptions added

Also available in: Atom PDF