That's an entirely appropriate failure mode for my case. If my app can't find an important file, then it should fail immediately, alerts then go off, dashboards are bleeding, ops is getting paged, etc.
For example: you store a conversion factor in you config file (eurostodollars=1.12 or whatever).
If you have an empty catch block, you now have a null Reader object or something. Next read will throw an IOException, which you also swallow and you now have an uninitialized config value. Except that one will be zero instead of null.
500 km further in your code, a month after you started the app, that zero gets used in your code.
amounttopay+=eurostodollars*euroamount;
I saw this kind of scenario again and again. No , the app cant possibly start without database, that never happens, and anyway the next user will notice the empty database. Except after power failure in the middle of the night, when the database is still booting up while your app is reading the config from it. When business hour start, everything seems fine. Until it isnt.
Checked exceptions are good if you want to be sure your caller does something when things go south. Some examples from my experience:
* Most things that should be told to the end user, i.e. Business Exceptions. E.g. a webshop user tries to buy something but your stock has been emptied why he was deciding if he should buy or not.
* Follow-up after a modification: If you wrote half a file, you can delete it in your catch IOException instead of letting it linger around. My company has a tendency to pick up and process any file found in an output directory as soon as you release the file lock. But just not filling your disk is good enough for me as reason.
Don't get me wrong, I also think that Java's checked exceptions are not really useful but your argument is very one-sided.