If checked exceptions were implemented in such a way that they were inferred, and they weren't erased in the byte code, much like how people use strong types now, they wouldn't be seen as hoops. Meaning, if you didn't explicitly handle a checked exception, it would automatically bubble up yet be visible to your IDE.
I would love if, at design time, all the possible exceptions that could happen were able to be inferred. But, the way it happens in java, it's entirely manual, and it won't catch things where I'm referencing compiled code. The design of checked exceptions in Java lead to all kinds of exception anti-patterns becoming common, just to shut up javac.
Exactly. I have no problem with a function declaring the sort of exceptions it can handle, although simply handling them when they occur is normally good enough.
I would love if, at design time, all the possible exceptions that could happen were able to be inferred. But, the way it happens in java, it's entirely manual, and it won't catch things where I'm referencing compiled code. The design of checked exceptions in Java lead to all kinds of exception anti-patterns becoming common, just to shut up javac.