This fix means that you won't notice when you accumulate other such resource leaks. When the shit eventually hits the fan, you'll have to deal with problems you didn't even knew you had.
These are the same noises that were made on the right prior to the election. As long as people are sufficiently mad about the status quo, the other party has a chance to take over.
This topic has been written about in more depth by people who didn't try to work it out by themselves.
The classical artists color wheel is based on pigments. Printers use dyes. Screens use light. That's the whole reason why the primaries are different. The wheels are just tools.
I don't think we disagree it's just a different perspective. The forced handling or propagation is what makes them annoying, but I think they're conceptually wrong.
It would be another matter if they were designed such that you could fix an issue and continue the call on the happy branch, but I suspect the cases where something like that would be applicable are very few.
> But importance of the failure is determined completely by the program, not the library.
Exactly. I think this is the real crux about what's wrong with checked exceptions. It puts the responsibility to decide what exceptions are important on the library, where it doesn't belong. Only the user of the library knows that.
It's more of an issue the more network-y and multi-cpu your ecosystem is. I find the post rather banal and obvious. The state is literally the how and what.