Apologies in advance if my comments below sound a bit harsh but I consider your arguments for using checked exceptions non-sense.
"It forces developers, who are often hurried, and who often make mistakes, to think about things that could go wrong, and deal with them"
Checked exceptions won't solve your problem here at all. If you need an instrument to force developers to think about things that could go wrong your team is screwed anyway.
"Much less time is spent reading and re-reading API documentation to make sure you've caught all the possible exceptions ..."
You are never ever going to catch all possible exceptions anyway (runtime exceptions and errors are still there even if you'd prefer to have checked exceptions only).
"Unchecked exceptions are a production run-time nightmare."
And you have to deal with them even if you use checked exceptions (again runtime exceptions and errors are still there). You have to have proper (unchecked) exception handling in the right places in your software.
Are you actually properly producing tests for your code before deployment-time ? Otherwise I would not get it why it would be nightmare.
"The best argument I've heard against checked exceptions is that they "bloat the code". It's true: checked exceptions requires more code.
Bloat causes development drag and makes the code more difficult to understand (more scrolling, jumping to different locations in the same file, etc.).
"But I'm writing code, not poetry."
I think you produce both.
I'd compare here checked exceptions to unchecked exceptions like what staticlly typed languages are to dynamically typed languages. And I've seen a lot of developers "loving" statically typed languages because the compiler tells them all their errors (at least they think so).
"Checked exceptions won't solve your problem here at all. If you need an instrument to force developers to think about things that could go wrong your team is screwed anyway."
It isn't about needs, it's about programming languages making it easier to write robust and reliable software. This benefits all developers, from inexperienced to masters. Even the best developers make mistakes and sometimes forget to check return codes.
Checked exceptions are just one useful tool in the toolbox. Another useful tool is dynamic strings (so that developers don't have to waste wetware cycles worrying about overflowing fixed size string buffers). Another useful tool is garbage collection (so that developers don't have to waste wetware cycles worrying about where and when to free memory).
These features lead to higher productivity and more reliable and robust software. Why wouldn't you want a tool that makes sure you check your return codes? Because it might force you to write "throws FooException" on your method signature, if you choose to handle that higher up the call stack? Oh, what a burden!
"You are never ever going to catch all possible exceptions anyway (runtime exceptions and errors are still there even if you'd prefer to have checked exceptions only)."
This is not a good argument against checked exceptions, this is an argument for using the appropriate type of exception for your current needs. Checked and unchecked exceptions are both useful tools.
Yes, sometimes developers use checked exceptions when they should use unchecked exceptions, and vice versa. And sometimes people use a big screwdriver when they should be using a hammer. Does that make screwdrivers or hammers useless?
"And you have to deal with them even if you use checked exceptions (again runtime exceptions and errors are still there). You have to have proper (unchecked) exception handling in the right places in your software."
I think you may simply be unfamiliar with when checked exceptions should be used, and when unchecked exceptions should be used.
Unchecked runtime exceptions represent conditions that, generally speaking, reflect errors in your program's logic and cannot be reasonably recovered from at run time; i.e., a bug in your program that will require code changes to fix. Generally speaking, you don't catch unchecked runtime exceptions, you allow them to bubble up to a high level handler. The high level handler will log the error and inform the administrator something went wrong, or display a (possibly localized) message to the user indicating that something went wrong, possibly requesting that they allow an error report to be sent to interested parties, etc.
Checked exceptions represent invalid conditions in areas outside the immediate control of the program (invalid user input, database problems, network outages, absent files). Generally speaking, you handle checked exceptions immediately (or almost immediately) and don't allow them to bubble up to a high level handler. These generally do not represent program bugs that require code fixes, it's just mundane but also important stuff your program logic should handle. By throwing checked exceptions in these cases, you eliminate a lot of burden on the caller to make sure they are handling all reasonable conditions.
"Are you actually properly producing tests for your code before deployment-time ? Otherwise I would not get it why it would be nightmare."
Not every code path is reasonably testable, plus tests are often the first thing to go during a crunch. Despite the best intentions, tests are not a cure-all. For best security, use multiple layers. For best software, use multiple layers. Checked exceptions are one of those layers: help your caller do the right thing, enforced by the compiler itself. Sure, tests are great, too.
"Bloat causes development drag and makes the code more difficult to understand (more scrolling, jumping to different locations in the same file, etc.)."
Since in real code you want to always handle return codes anyway, checked exceptions introduce no unnecessary bloat.
"I think you produce both.
I'd compare here checked exceptions to unchecked exceptions like what staticlly typed languages are to dynamically typed languages. And I've seen a lot of developers "loving" statically typed languages because the compiler tells them all their errors (at least they think so)."
At this point I'm fairly certain your misunderstanding comes down to not knowing when and where to use checked exceptions, and when and where to use unchecked exceptions. You're conflating all exceptions into one gigantic indivisible entity and asking, "Why have both?" The answer is: because they're used for different things! I hope I've sufficiently answered that in more detail above.
I'm in favor of static typing over dynamic typing as well, but that's a whole other kettle of fish. However, I'm gratified to see that the wider developer community is finally accepting that static typing can be done in such a fashion that it's just as powerful and expressive as dynamic typing, but without what many consider unnecessary bloat or limitations. Languages will continue to evolve, and I'm confident static typing will win.
All of the above is colored by my application domain (I work on server applications that must run flawlessly for at least weeks, usually months, or even years at a time). Robustness and reliability is at or near the top of my list of requirements for a programming language. Different application domains may trade robustness and reliability for other things, which might make sense for those particular application domains.
Checked exceptions make my life much easier and result in more robust and reliable software, because I simply can't forget to check for things like "file not found" or "connection refused" or "invalid user input" -- my tools makes sure I do that. Thanks, tools!
(However, as a user as well as a developer, I wish all developers put robustness and reliability first.)
"It forces developers, who are often hurried, and who often make mistakes, to think about things that could go wrong, and deal with them"
Checked exceptions won't solve your problem here at all. If you need an instrument to force developers to think about things that could go wrong your team is screwed anyway.
"Much less time is spent reading and re-reading API documentation to make sure you've caught all the possible exceptions ..."
You are never ever going to catch all possible exceptions anyway (runtime exceptions and errors are still there even if you'd prefer to have checked exceptions only).
"Unchecked exceptions are a production run-time nightmare."
And you have to deal with them even if you use checked exceptions (again runtime exceptions and errors are still there). You have to have proper (unchecked) exception handling in the right places in your software.
Are you actually properly producing tests for your code before deployment-time ? Otherwise I would not get it why it would be nightmare.
"The best argument I've heard against checked exceptions is that they "bloat the code". It's true: checked exceptions requires more code.
Bloat causes development drag and makes the code more difficult to understand (more scrolling, jumping to different locations in the same file, etc.).
"But I'm writing code, not poetry."
I think you produce both.
I'd compare here checked exceptions to unchecked exceptions like what staticlly typed languages are to dynamically typed languages. And I've seen a lot of developers "loving" statically typed languages because the compiler tells them all their errors (at least they think so).