3 ms·

The problem with checked exceptions is that they constrain implementations by what possible failure states they could have. I.E. the implementations of an inter

by Felz 8y ago

The problem with checked exceptions is that they constrain implementations by what possible failure states they could have. I.E. the implementations of an interface with a method in it that declares no exceptions will either never call anything that could throw a checked exception, it will internally handle its checked exceptions, or it will wrap them in an unchecked exception. In practice, the first is a straitjacket, the second leads to ignoring errors you can't propagate, and the third is boilerplate that makes it harder to actually catch the exceptions when you need them. What would've made them good would be a static analysis of some sort that could divine all possible exceptions thrown by a method call and its dependents based on its code, but in Java a class can always override another class and do something entirely different so that's not possible.

Terr_ 8y ago
Try reading this aloud: "The problem with return-types is that they constrain implementations by what possible success states they could have." Checked exceptions are (for the most part) the mirror image of checked returns! Both describe and circumscribe your expectations for what comes back from the method, the only difference is one is happier than the other. They follow the same kinds of type-rules, and the real problem is entirely on the human end: It's harder to imagine failure scenarios, features are prioritized over error-handling, and people don't like to do it if they can avoid it somehow. > What would've made them good would be a static analysis of some sort that could divine all possible exceptions thrown by a method call and its dependents based on its code Again, ask yourself "why don't we already do this but with return types?" Probably because it's horribly impractical in most cases and and outright impossible in others. For example, when it comes to interfaces, abstract-methods, or overridden methods... All of those involves concrete implementations that haven't been made yet. Heck, they might not get created until months or years after you ship your .class files. Then some random guy you've never met says: "Oh, hey, I can fix my problem by creating my own implementation based on their interface..." So unless your compiler can literally see into the future, you've got to set down your type-expectations first. > but in Java a class can always override another class No, even if all classes were marked "final", you'd have the same problem when it comes to using interfaces.

by Felz 8y ago

Terr_ 8y ago

Try reading this aloud: "The problem with return-types is that they constrain implementations by what possible success states they could have." Checked exceptions are (for the most part) the mirror image of checked returns! Both describe and circumscribe your expectations for what comes back from the method, the only difference is one is happier than the other. They follow the same kinds of type-rules, and the real problem is entirely on the human end: It's harder to imagine failure scenarios, features are prioritized over error-handling, and people don't like to do it if they can avoid it somehow. > What would've made them good would be a static analysis of some sort that could divine all possible exceptions thrown by a method call and its dependents based on its code Again, ask yourself "why don't we already do this but with return types?" Probably because it's horribly impractical in most cases and and outright impossible in others. For example, when it comes to interfaces, abstract-methods, or overridden methods... All of those involves concrete implementations that haven't been made yet. Heck, they might not get created until months or years after you ship your .class files. Then some random guy you've never met says: "Oh, hey, I can fix my problem by creating my own implementation based on their interface..." So unless your compiler can literally see into the future, you've got to set down your type-expectations first. > but in Java a class can always override another class No, even if all classes were marked "final", you'd have the same problem when it comes to using interfaces.