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.
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."