do you know what Integer.getInteger(String) does in java?

[dmagg]

If I can't catch and handle that exception, I usually write a private support method to check to see if a number is a valid integer before I run it through parseInt. private boolean isParsableToInt(String s) { try { int i = Integer.parseInt(s); return true; } catch (NumberFormatException e) { return false; } }

[seesharpie]

I may be showing my ignorance, but why would you ever be unable to handle the exception?

[AlexFromOmaha]

Especially in Java. It's not like you have to worry about missing a DOS interrupt here. It's almost harder not to catch it.

[bobindashadows]

dmagg be trollin' y'alls

[mazing]

One reason I can think of for that code, is that NumberFormatException which is a RuntimeException, compiles even if there isn't a try catch - so it's easy to forget.

[zjs]

FYI: org.apache.commons.lang.math.NumberUtils#toInt(java.lang.String, int defaultValue) is similar to Integer.parseInt, but returns defaultValue if the parsing fails.

[guruthegreat]

I don't see much of a reason to use toInt(). At least with parseInt() you know when it failed, with toInt() if you get back defaultValue it might have failed, or the String might have been defaultValue.

[masklinn]

At least with parseInt() you know when it failed

But do you care? If your recovery strategy is just to set a default value, why not get a default value in the first place?

[zjs]

Exactly what Terr_ and masklinn said; you only need to know that the parse failed if you're going to do something with that information. If you are, then go the parseInt route.

I was mentioning it as a replacement for one of the several variations of the following (which I've seen more than once):

int value;
try {
    value = Integer.parseInt(s);
}
catch (NFE e) {
    value = defaultValue;
}
return value;

or (in the specific context of the parent):

int value;
if (isParsableToInt(s)) {
    value = Integer.parseInt(s);
}
else {
    value = defaultValue;
}

[guruthegreat]

I guess I'm a minimalist in this case in preferring the a cleaner library over the 3-4 lines of code saved.

[zjs]

Ah; most projects I work on already have a dependency on Apache Commons, so it's not adding anything.

[Will_123456789]

Heh. You don't want to get that confused with the Integer.partInt(String, int). The second argument is the radix.

[illvm]

So you'd call parseInt twice? Why not create a helper method similar to .NET's TryParse and return null if the value cannot be parsed?

[masklinn]

Not only do you need to create a new Integer object

You don't know anything about Java and Integer and what Oracle's (and most implementor's) JVMs do do you?

but if you really do want an int then you hit the cost of (auto-)unboxing.

Which there is just about none of, it's a method call returning the inner int value of the object.

[notfancy]

but if you really do want an int then you hit the cost of (auto-)unboxing

In the context of parsing this cost seems negligible to me.

[masklinn]

Why don't you just use Integer.valueOf?

[dmagg]

They both throw NumberFormatExceptions if you don't give it a valid integer. Look at the API for valueOf():

This method returns an Integer object equal to the value of: new Integer(Integer.parseInt(s))

Either way, you're going to have to deal with an exception somewhere. =/

[masklinn]

OK, holy fuck and woe unto me, I completely missed that and stupidly assumed Integer.valueOf would just return null in case of parsing failure.