Int? double? no, int?

zelmak

try
{
   data.set(Integer.parseInt(thisStr));
} 
catch(NumberFormatException ex) 
{
   try 
   {
     double num = Double.parseDouble(thisStr);
     data.set((int)num);
   } 
   catch(NumberFormatException ex) 
   {
     //log the error
   }
}

bad? hrm ... I guess it depends on the requirements ... :)

however, the code is a bit uneven ... in the double conversion, there's a secondary temp variable where there isn't with the int ...

but allowing a 'double' in the input, then down casting it to int ... ugh ...

then, putting in a comment to log the error, but not actually logging the error ... :sigh:

TGV

Ah, that's soooo sweeeeeet. Look how forgiving this code is. It even doesn't fill up the log file.

BTW, I'm a bit unsure about Java's casting rules, but what happens when you fill in, e.g., 1e38? That doesn't generate a NumberFormatException.

@zelmak said:

bad? hrm ... I guess it depends on the requirements ... :)

Yes. I have had one occasion where code pretty close that to that was needed, as far as idea goes anyway. The implementation differed. We had to parse data from different source and sometimes it was returning floats eventho spec said it should return ints (this could also happen if data is coming from user). We didn't cast those doubles to int directly tho and rather used Math.round(). I could see direct casting being okay if it didn't really matter that the number was off by 1 and that part of code was being executed a lot (I cannot really think any situation where both of these would true and using Java would be a good idea tho).

Of course ignoring the exception most likely isn't a good idea.

fatbull

@TGV said:

BTW, I'm a bit unsure about Java's casting rules, but what happens when you fill in, e.g., 1e38?

The result is Integer.MAX_VALUE (JLS 5.1.3).

JimLahey

Jesus H Christ.

I know it's Java so I can't be sure, but if this abomination were in C# there would be an InvalidCastException thrown in the case that it is in fact a long. Aside from the fact that it's a nested try..catch, the developer responsible clearly doesn't know the difference between long and int. What odds can I get on the numeric value actually being stored as a string?

I'm sure that implementing this in .net would produce the following in ILSpy:

fail(this){}

Medinoc

No, there would be an OverflowException and only in a checked context.

Casting a double into an int only throws InvalidCastException if the double is boxed.

TGV

@fatbull said:

@TGV said:
BTW, I'm a bit unsure about Java's casting rules, but what happens when you fill in, e.g., 1e38?
The result is Integer.MAX_VALUE (JLS 5.1.3).

Sweet. What a great idea for untraceable bugs.

rstinejr

Why not just do something like:

   try 
   {
     double num = Double.parseDouble(thisStr);
     data.set(Math.round(num));
   } 
   catch(NumberFormatException ex) 
   {
     //log the error.  Really.  Or maybe even don't catch the exception.
   }

Not a good idea if you are processing a gazillion of these and the data is mostly ints, so YMMV, but parseDouble can handle int format.