Error in String to Double conversion

Question

Error in String to Double conversion

Asked 6 years, 9 months ago

Viewed 681 times

2

Setting:

public void metodoX(Double valor) {

    DecimalFormat df = new DecimalFormat("0.00");
    String valorRound = df.format(valor);
    Double valorRound2 = Double.parseDouble(valorRound);
    ...
}

Error:

Caused by: java.lang.NumberFormatException: Invalid double: "3,67"

Line with error:

Double valorRound2 = Double.parseDouble(valorRound);

Details:

The app is rodando perfeitamente no emulador API 23, but running in the celular API 23, causa esse erro.

Why only on the mobile gives the error ?

I’ve tried to:

Double valorRound2 = Double.valueOf(valorRound);

2

He’s expecting a figure with . for decimal separator, not comma. I don’t know why it produces this comma because apparently the decimal format should be with . ; one of the probable causes is that the emulator is with English locale and the Portuguese device

– Jefferson Quesado

2017/12/18 at 16:09
@Jeffersonquesado understood, it can be locale... you think with the bigdecimal, would solve ?

– rbz

2017/12/18 at 16:31
If you’re not in scientific applications, I don’t even know why to use double for starters. I would always use BigDecimal. You have a very interesting question on the subject, https://answall.com/q/219211/64969

– Jefferson Quesado

2017/12/18 at 16:33
@Jeffersonquesado So basically better use the BigDecimal for all cases that do not need to be floating (I believe 99% do not need more than 4 homes after the comma) !? Taking advantage, Bigdecimal already contains house limitation ?

– rbz

2017/12/18 at 16:58
1

Using Bigdecimal will not solve the NumberFormatException.

– ramaral

2017/12/18 at 17:02
The accuracy is arbitrary. I work with 30 to guarantee me in the calculation of taxes (even the user informing at most 2 decimal places of value, 4 houses of what we have stored in the table of taxes and 4 houses in the discount of the sale of the product). I believe your case is one of arbitrary accuracy. This will not avoid formatting issues, as @ramaral pointed out.

– Jefferson Quesado

2017/12/18 at 17:10

Show 1 more comment

2 answers

2

Why only on the mobile gives the error ?

Gives error in one and not in the other because the decimal separator depends on the Locale defined in the device. In some cases it is ., in others is ,.

I assume that value is entered by the user, so you have to ensure that it is entered in the correct format.

One of the possible ways of doing this is to indicate android:inputType="numberDecimal" in the Edittext statement:

<EditText
   android:id="@+id/edittext"
   android:layout_width="fill_parent"
   android:layout_height="wrap_content"
   android:text="0" 
   android:inputType="numberDecimal"/>

Edit after comment:

It is not in the input no, it is of a Seekbar with variation 0.01(...)

In that case do so:

DecimalFormat df = (DecimalFormat) NumberFormat.getInstance();
df.setMaximumFractionDigits(2);
df.setMinimumFractionDigits(2);

String valorRound = df.format(valor);
Double valorRound2 = Double.parseDouble(valorRound);

It is not in the input no, it is of a Seekbar with variation 0.01 ! But I did not know this, it is already another new ! Thanks !

– rbz

2017/12/18 at 17:02

Browser other questions tagged java android

You are not signed in. Login or sign up in order to post.

by Paulo Roberto Rosa • **8,979** points · Answer 1 · 2017-12-18T16:15:08+00:00

Explanation

You are having an exception for some reason, so in a situation where there may be exceptions, one should treat the exceptions with block try/catch.

Codes

Resulting in this way:

public void metodoX(Double valor) {

  try {
    DecimalFormat df = new DecimalFormat("0.00");
    String valorRound = df.format(new Double(valor));
    Double valorRound2 = Double.parseDouble(valorRound);
  } catch (NumberFormatException e) {
    valor = 0; //valor padrão
  }
  ...
}

However, the problem at issue is apparently with Locale and its differences in Doubles treatment between , and ., so I would recommend using a DecimalFormatSymbols to avoid comma problems, in this way:

Locale meuLocale = new Locale("pt", "BR");
DecimalFormatSymbols simbolos = new DecimalFormatSymbols(meuLocale);
simbolos.setDecimalSeparator(',');
simbolos.setGroupingSeparator('.'); 
DecimalFormat df = new DecimalFormat(valor, simbolos);

(according to the comment of @Jefferson Quesado, probably the locale is the cause of the working divergence, so applying this last block of code would solve.)