Web applications should generally have some sort of generalized handler around the entry point that sends back a web page saying "Something went wrong and we didn't know what else to do, so we're showing you this error page. HTTP status code 500." Production software should generally log a stack trace rather than simply crashing, but checked exceptions make it harder to do that.
A 500 error is a complete outage for every affected page. Most web app pages contain a lot of boilerplate -- headers, graphics, navigation elements, footers, and so forth, so a single error in a trivial component can cause an outage for an entire application unless it is localized properly.
Imagine following example: you signed contact to guarantee 99,999 uptime - 8-9 hours of downtime per year. First your downtime is 12 hours. Now you need to work more than 1 year without any errors. Any "500" error code can cost hundreds of thousands of dollars.
How you will do error handling and exception handling in that case? If there 1 chance per million that something will work incorrectly due to solar radiation or power fluctuation, how much such temporary failures you will see when your system handling more than 100 millions of requests per day? If you restarted database and all connections to database are broken, should all your current users see 500 error code?
PS.
That is real story. ;-)
PPS.
I used RecoveryManager to handle errors in the my system. It is very simple: when it receiving an error, it uses it configuration to determine action to take (e.g. call helper method) and responding to caller with code to indicate what caller should do: throw exception to higher level or just try again for few times.
