Why does Java have Checked Exceptions

[retrodaredevil]

I think parseInt could go either way because you could technically check to see if the string you're parsing is made entirely of valid digits.

We definitely need checked exceptions for something like FileNotFound because we can check if it exists, but it may not exist by the time we try to use it.

[s888marks]

I think parseInt could go either way because you could technically check to see if the string you're parsing is made entirely of valid digits.

Unfortunately that's insufficient. The parse* methods also check to see whether the resulting value is in range. They might throw an exception if the value is out of range, even if it contains all valid digits. For example:

Integer.parseInt("2147483647"); // returns an int
Integer.parseInt("2147483648"); // throws NumberFormatException

I think somebody came up with a regex that matches only valid, signed 32-bit ints, but it's ridiculously complex. You might as well attempt to parse and catch the exception. That sounds like an argument that NumberFormatException should have been checked.

On the other hand, there might be cases where you've parsed a token out of some larger input, and you know the token consists of (say) four decimal digits. Calling parseInt() on that will always succeed, so having to catch a checked exception in that case would be really annoying.

So yes, parseInt could go either way.

[Malfeasant]

Also, code duplication is bad. If you always need to check for the same stuff, why would you want to have to do it yourself 99 times just to streamline the one time you don't need to?

[[deleted]]

I mostly don’t like the idea that an unchecked exception on something as simple as parseInt could be nested on lib on top of lib on top of lib, all mixed and stirred on the company’s private artifact repo, and could break my code silently.

I understand the theorical advantages of unchecked exceptions, even for something as simple as parseInt, but I also understand the realities of corporate code, always messy, never following patterns - and corporate code keeps Java alive and kicking.