I have a really simple comparison I am looking at where the outcome is throwing me for a loop. I get a NumberFormatException even though I am checking to make sure this doesn't happen. The check is not working.
I don't understand why the param != null is catching null values and returning value instead of barfing.
Instead it performs the parseInt anyway and throws a NumberFormatException.
I'm embarrassed to ask for help on something that should be so easy, so please be kind.
The check against null prevents NullPointerExceptions, but nothing prevents the parameter from not being a valid number; parseInt("foo") or parseInt("1.0") or parseInt("one") will all throw NumberFormatException. There's no way to avoid it, so don't try; instead, catch the exception, and either supply a default value, or report the problem, as appropriate. The first alternative might look like
Thanks for the responses. I do acutally like the try/catch solution the best, since I just found out the problem is actually that the value null is "null". Somewhere someone is initializing the value to the string "null". Nobody knows why. So the value isn't null afterall which falls right into your response.
There is some nervousness about implementing something like this because no one knows what would change if we checked this way because we have no idea what the original intent of the developers were.
I'll try it out and see if I can break some stuff reeeal good (but I doubt it).
In a JSP page, scriptlet expressions that evaluate to null emit the String "null". I'd bet dollars to donuts that there's a form element on your page whose value attribute is such a scriptlet expression.
When the form is submitted, the value of the element is then "null" rather than the empty string or a true null.
The fix is to check on-page for this condition. For example, rather than:
or some other means to make sure that you don't get the "null" as the form element value.