You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I propose adding another variant of Decimal128 rounding mode. I will call it "prohibited". It will simply throw an error if exact result cannot be represented as Decimal128. The error should be throw in all cases when resulting mathematical value cannot be stored in Decimal128. This includes all kinds of overflow, underflow and rounding.
Why I want this? Well, because when dealing with money, one often needs to get exact answer or no answer at all. I. e. sometimes visible failure is better than inexact answer.
COBOL had this feature for many decades. COBOL allows one to specify so-called "rounding mode". One of possible rounding modes is "rounding mode prohibited", which is similar to this proposal. Are we worse than COBOL? I don't think so. This would be absurd if we in 2024 don't have this old COBOL feature
The text was updated successfully, but these errors were encountered:
I propose adding another variant of Decimal128 rounding mode. I will call it
"prohibited"
. It will simply throw an error if exact result cannot be represented as Decimal128. The error should be throw in all cases when resulting mathematical value cannot be stored in Decimal128. This includes all kinds of overflow, underflow and rounding.Why I want this? Well, because when dealing with money, one often needs to get exact answer or no answer at all. I. e. sometimes visible failure is better than inexact answer.
COBOL had this feature for many decades. COBOL allows one to specify so-called "rounding mode". One of possible rounding modes is "rounding mode prohibited", which is similar to this proposal. Are we worse than COBOL? I don't think so. This would be absurd if we in 2024 don't have this old COBOL feature
The text was updated successfully, but these errors were encountered: