What do you mean when you say "exceptions should be rare"? Do you mean they should not occur frequently during runtime, or that it should be rare to see explicit exception handling in a piece of code?
Parsing input, handling I/O is a good chunk of what a lot of run of the mill software does. Since this is Java and exceptions are the main way of expressing fallibility, I’m at a loss as to what should code that needs to indicate fallibility should be using other than exceptions.
Return values obviously, with suitably designed method contracts. Some (maybe most) types of I/O errors are proper exceptions. Parsing failures are not.
So now you have two different error paths, one in which the file can't be accessed, and one in which the file can be accessed but the contents are corrupted? The developer must handle exceptions and they must still check if the function returned some sentinel error value?
What's the point of forcing two different error paths on the developer?
They are different classes of errors, so you want different error paths. Parsing errors are common and should be handled locally with all of the usual logic. Exceptions are not supposed to be common errors which is why they trigger non-local control flow.
