Checked exceptions require that the calling function acknowledge that an error has occurred
But why do they require the client to acknowledge the error? Better stated, why would one use a checked exception versus an unchecked? The general wisdom (and perhaps this is where I'm mistaken) is that checked exceptions generally indicate a more recoverable error. This is why checkedness doesn't belong in the function itself: it's an indication to the caller of the error's recoverability, which is completely unknowable.
Note that I was not arguing for checked exceptions. Rather, I was arguing that your argument does not support your conclusion.
With that said, I think it may be reasonable to say "You may be able to recover from a missing file, but no one can help you if this pointer is null." It's the difference between a logic error in the program (null pointer exception, array out of bounds exception) and configuration errors (missing file, lost connection). Checked exceptions are typically explicitly thrown by the called function; unchecked exceptions are typically encountered because the called function itself had an error. In other words, checked exceptions are when the called function recognizes an error, and throws it up to its caller.
So, I am able to distinguish them myself. But I'd still rather not have checked exceptions. The mentality of "acknowledge all errors" makes more sense in the error-code model, as seen in C programs. In that case, if you don't at least check for and report all possible errors that can arise from calling a function, then they will never get reported, and your program will silently be wrong.
Note that I was not arguing for checked exceptions.
Right, I understand that. And I was merely pointing out a flaw in your argument against my argument.
You may be able to recover from a missing file, no one can help you if this pointer is null
My argument (which you seem to be doing a great job of ignoring) is that this distinction is completely unreasonable. As the calling function, I am passing in the pointer, therefore I am the only one who can know whether the null pointer is a recoverable issue! Consider the ArrayOutOfBoundsException - perhaps the array bounds are passed in from the user interface, and the error should be trapped and reported to the user. This checked / unchecked distinction is simply nonsensical from the called function's point of view.
Checked exceptions are typically explicitly thrown by the called function; unchecked exceptions are typically encountered because the called function itself had an error
This is not typical, is not how you are using them in your examples, and also makes no sense. What is the difference between encountering a particular error within a function or a sub function? What if the logic in the function is later extracted into a subfunction?
I'm sorry if you feel that I'm ignoring your distinction. I'm not trying to ignore it, but argue that I think we can distinguish between "likely recoverable" and "likely not recoverable" for most cases. Nothing prevents you from catching unchecked exceptions. So if you know that you're passing in a may-be-null-pointer-and-it's-okay, then you can do an unusual thing and catch that exception. I agree that we can't classify all exceptions as recoverable or not recoverable from inside the called function, with full accuracy. But I disagree that we can't make reasonable guesses that will be true in most cases.
The function may encounter an error but it is not the caller's fault - that's what I mean by "the called function itself has an error."
Sure, we could guess at all sorts of things from within a function. We could guess that the function is running from a terminal, and simply print the result of the function to stout. Hell, we could guess what the caller is going to do with the result of our function and just do that instead! Why even have a caller at that point?
Of course I'm using hyperbole to point out the absurdity of making this distinction, which on the surface may seem reasonable. The fact is, however, the fewer assumptions a function makes about it's calling context, the better. The whole point of functions is that they are to be reused in ways the author may not have intended. The checkedness of an exception is an assumption about the calling context of a function which should not exist.
But why do they require the client to acknowledge the error? Better stated, why would one use a checked exception versus an unchecked? The general wisdom (and perhaps this is where I'm mistaken) is that checked exceptions generally indicate a more recoverable error. This is why checkedness doesn't belong in the function itself: it's an indication to the caller of the error's recoverability, which is completely unknowable.