在Java的UI中显示资金的正确方法是什么？

Question

On the backend I'm storing money values in a Money class which wraps a BigDecimal and sets rounding to be always Half Even with scale 8. All basic operations work fine and behave as expected. But I need to show those values to the user with scale of 2, and that's bringing me rounding errors.

For example, I have these values in the backend:

a = 109.11432
b = 9015.57069
c = 9124.68501

Each one of them is formatted to the pt-BR locale:

NumberFormat nf = NumberFormat.getInstance();
nf.setCurrency(Currency.getInstance(new Locale("pt","BR")));
nf.setMinimumFractionDigits(2);
nf.setMaximumFractionDigits(2);
String n = nf.format(valor);
return n;

And then I have

a = 109,11
b = 9.015,57
c = 9.124,69

And that's ok, at first. But c should be a + b. With the real values, this is guaranteed, but the rounding gives me a 0.01 error.

What's the proper way to handle this situation?

Answer 1

It seems to be doing exactly what you want it to. The way you are storing it, you are storing far beyond 0.01. If that is not your intention, then stop doing it :)

If you want a + b to equal c with 2 decimal places, then you need to round before doing the addition. The solution to your issue depends on the requirements of your application. One common way of storing money is actually with an integer. That way, you cannot store fractions and you could never have the issue you are currently describing.

But it really depends on your requirements. Are you required to do money arithmetic based on 0.01, or on full accuracy and then round the end result? That's a business question, not a technical question.

Answer 2

Note that a NumberFormat also can have a rounding mode .

But ultimately, no rounding method can fulfill a business requirement like "these values have to add up to this one" without being designed specifically for that case. Round-half-even is designed to avoid a large-scale bias, not single last-decimal errors. So where do you originally get the data from? That's where you have to make sure that the rounding preserves the total.

Is storing the data with 8 fractional digits really a requirement, since you display only 2? I'd also question the assumption that "With the real values, this is guaranteed", since the same thing could happen there, when rounding to 8 digits after whatever calculation produced the values.

Answer 3

If I were writing a money class, I would make it consist of two integer portions - dollars and cents (or reais and centavos, or whatever). That way you never end up with fractional cents. You just have to handle rolling over 100 cents in the addition and subtraction operations.

EDIT:

The comment to my original response has a good point. Another option would be to just store the number of cents, then divide by 100 when you need to display.