The reality is that programmers do not have the time to handle every single possible exception. I reckon every few function calls you make could potentially trigger an exception. You generally just have a catchall (or not, and let the program abort), and then catch certain specific exceptions that are common enough.
Yes unchecked exceptions are nice. However it would be nice if the compiler could enforce documentation of possible exceptions raised by a method. Something like the throws keyword of Java with unchecked exceptions.
That way you (through the IDE) could know at any point of your code what exceptions could happen (and not have to guess or go through all the called code to identify them).
Absolutely. I handle the ones that are common enough to be worth investing time in (or have severe enough consequences). The rest recover as best they can and tell the user "Something bad happened. Call the helpdesk." (while logging a stacktrace).
> I reckon every few function calls you make could potentially trigger an exception.
One Java module I had the misfortune of writing theoretically had to deal with checked exceptions on the majority of its calls, and the only possible response to virtually all of them was to crash, because in that context, it could only have meant someone had either ripped the DRAM off the board, or placed the board in a particle accelerator.
And there was nothing particularly special about the module aside from the extreme concentration. Every piece of Java I've ever written or even looked at has this same problem on a reduced scale.
My point is to show how utterly broken and worthless the concept is. Either there's a ton of exception-"handling" boilerplate that does nothing useful, or there's "throws Exception" everywhere, itself useless boilerplate that exists only to tell the compiler to buzz off.
