[ruby-core:86006] [Ruby trunk Bug#14588] math library functions should NOT raise exceptions

[spamscud2003@yahoo.com]

Issue #14588 has been updated by Anon92929 (Anon Ymous).


> What Github issue and bugs.ruby-lang.org issue are you referring to?
>> We REFUSE to attempt .to_s automatically

> It seems you're wanting Ruby to be weakly typed. Ruby is strongly typed and is likely to stay that way.

Strong typing is not the issue, the issue is codebase FRAGILITY, and ruby is becoming increasingly fragile. Strong typing is fine, but the problem is that every time there's any sort of error, it throws an assert, and the number of possible errors is increasing over time. For example, what should it do when it fails, during a puts or print statement, to convert an int to a string, for printing? Should that cause an assert, or should it, intelligently, just print the output statement? How many people's hours have been wasted trying to make sure that print statements don't assert? 


> "." is not technically a number
>Did you think a period was a number? I'm confused what you mean by this. Maybe a link to the issues you're referring to will clear this up.

To me, this should return 0, or NaN. What will happen in reality? It will break and then you will have to customize your codebase to handle that one dataset that had a stray ".", because everything halted and the program asserted instead of giving a warning. Now every time I update any math library I have to worry about whether there will be new types of unhandled, breaking changes to the way NaN is handled in three separate sub-libraries. Great work. 


----------------------------------------
Bug #14588: math library functions should NOT raise exceptions
https://bugs.ruby-lang.org/issues/14588#change-70868

* Author: Anon92929 (Anon Ymous)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: 
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
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!!!


BUG RESUBMITTED. 

The bug was rejected at github because I was referred to open a ticket at ruby-lang.org.

The bug was rejectet at ruby-lang.org because the ticket was closed at github.

Not cool, guys.



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