2

Our middle tier sends us serialized objects and sometimes a 0, due to some math operations in java on the server, come through as 0E+3. When deserializing the object we get an XmlException --> System.OverflowException because the value is too large or small for a decimal.

Why can't decimal.Parse handle this conversion?

Is there a way to protect our client from these numbers coming in this way?

Ben
  • 597
  • 1
  • 6
  • 19

3 Answers3

3

You could try:

decimal.Parse(numberText, System.Globalization.NumberStyles.Any)

EDIT:

This doesn't work for 0E+3 unfortunately

Works:

Console.WriteLine(decimal.Parse("0", System.Globalization.NumberStyles.Any));
Console.WriteLine(decimal.Parse("123.45", System.Globalization.NumberStyles.Any));
Console.WriteLine(decimal.Parse("1.35E+6", System.Globalization.NumberStyles.Any));
Console.WriteLine(decimal.Parse("1.54E-5", System.Globalization.NumberStyles.Any));

Doesn't work:

Console.WriteLine(decimal.Parse("0E+3", System.Globalization.NumberStyles.Any));

Is the problem number always 0E+3?

If so, you could write a helper method to handle this:

decimal ParseDecimal(string number)
{
    if (number.Equals("0E+3", StringComparison.OrdinalIgnoreCase))
    {
        return 0;
    }

    return decimal.Parse(number, System.Globalization.NumberStyles.Any);
}
Patrick McDonald
  • 64,141
  • 14
  • 108
  • 120
  • In this case it was 3. I don't know if it comes through with other values. We aren't managing the parsing though. It is being deserialzed within the json components. – Ben Apr 29 '11 at 16:42
  • Is there a way to tell the json component how to parse something, or what type to map it to? (you could make a custom type that can deserialize an 0E+3 string maybe) – Random832 Apr 29 '11 at 16:48
  • I guess this is a bug in decimal.Parse, it might be worthwhile raising this on Microsoft Connect (http://connect.microsoft.com/). You might have to write a custom deserializer (no idea how to go about doing this) or else specify them as strings on your XML and manually parse. – Patrick McDonald Apr 29 '11 at 17:02
  • I agree this is a bug. I don't know why the parse routine cannot handle this. I think I may have to either find a way to do a custom serializer or take the value into a string and then parse manually into a decimal. – Ben Apr 29 '11 at 20:21
  • C# can handle 0.000E+3 though and turns it into decimal 0. It cannot handle 0.00E+3. It gives the same error. – Ben May 03 '11 at 18:04
1

Java is probably doing this calculation as a double (which means you also don't need the extra precision of a Decimal) if they come out this way... consider using double instead of decimal.

If you have to, just trim out the E[+-]?([0-9]+)$ manually with a regex and do the multiplication yourself. Or match ^0E as a special case (it seems NumberStyles.Any can't handle it) and just return 0.

Random832
  • 37,415
  • 3
  • 44
  • 63
  • The java side is using BigDecimal. Java also receives an xml document with exponents in certain quantity fields and then subtracts these values. Sometimes the values result in 0. When java is managing BigDecimal and starting with an exponent, does it return subtraction results as exponents as well? – Ben Apr 29 '11 at 16:24
0

Change it to a float or double and it will parse it correctly. Although be careful, the precision will be much lower (7 digits for float or 15-16 digits for double vs 28-29 for decimal).

Yuriy Faktorovich
  • 67,283
  • 14
  • 105
  • 142