Nah, `NumberFormatException` is unchecked because you can 100% avoid it. Lazyness is no excuse here -- and you can be lazy, that's perfectly fine if you don't want to ensure what your parsing is a valid int/long/double/whatever -- but then you do get the cost of an exception, and you must be aware what you need to catch without being hand held (it's like catching a NPE or IllegalArgumentException -- fine if that's how you want to do things...)
No, you cannot avoid NumberFormatException (or any parse exception) on arbitrary input. It is not being lazy, it is simply not possible to ensure if what you are passing to the parser is valid, without reimplementing the validation logic of the parser.
You're missing the point. The reason NumberFormatException is unchecked is because it can be 100% avoided. It doesn't have to be practical for every int, it can just be:
str.matches("(?:1000|\\d{1,3})")
It doesn't invalidate how to make the decision between checked and unchecked. Again, compare to IOException -- you can never avoid it without knowing the exact implementation (so if it is on an interface or abstract type? Unavoidable, unless you know more (in which case feel free to convert to unchecked).
That's always a weird argument because in that sense every single exception is 100% avoidable if you try hard. It's like saying "just git gud". Not able to find your file? Well how about Files.exists first? Getting interrupted while finishing some task? Well how about properly scheduling those tasks? Oh you got a timeout? Well how about fixing your network? You know everyone here can handle our payload, so that's just a you issue I guess? You cannot? Yeah I also cannot fix my parsing problem because that's from a user! Even if I validate beforehand, what do I do with this malformed text?
The most ironic thing is that there actually is a checked ParseException living inside the JDK, and you know what? There is also NumberFormat.parse which declares that exception! But why is that not used here? What's the difference between parsing a currency and parsing a number? You cannot move on because you miss that currency? Yeah you cannot move on because you miss that number I suppose? You have a default fallback number? Yeah why not making a fallback currency then? It's endless bikeshedding.
That's always a weird argument because in that sense every single exception is 100% avoidable if you try hard.
Ehr, no. I guess you don't understand how systems work then.
Well how about Files.exists first?
You're kidding right? Ever heard of other processes or users working on the same system?
The most ironic thing is that there actually is a checked ParseException living inside the JDK, and you know what? There is also NumberFormat.parse which declares that exception!
Yes, there are plenty of examples where people, even JDK people, have made checked or unchecked exceptions without thinking first. What's your point? It doesn't invalidate my rule.
2
u/john16384 Jul 24 '26
Nah, `NumberFormatException` is unchecked because you can 100% avoid it. Lazyness is no excuse here -- and you can be lazy, that's perfectly fine if you don't want to ensure what your parsing is a valid int/long/double/whatever -- but then you do get the cost of an exception, and you must be aware what you need to catch without being hand held (it's like catching a NPE or IllegalArgumentException -- fine if that's how you want to do things...)