3 ms·
Declaring only some of the things that might go wrong, which is the case with checked exceptions, does not solve the problem you described and only makes it mor
by twblalock 8y ago
Declaring only some of the things that might go wrong, which is the case with checked exceptions, does not solve the problem you described and only makes it more difficult to write code.
If every kind of exception was checked, then every method in Java, including constructors, would need to declare that it throws RuntimeException and IOException and NullPointerException and NoClassDefFoundError and InterruptedException because those things could happen in any method.
So we settle for declaring the type a function is expected to return, with the understanding that if something exceptional occurs a magical thing called an Exception will be thrown and it's not handled the same way as a return value. This lets us get our jobs done. It's engineering, not science.
When you solve the halting problem we can talk about formalizing every possible failure state as a return value. Until then we will get on with our lives.
- Terr_ 8y ago> If every kind of exception was checked [...] When you solve the halting problem Hold it: I said nothing remotely like that. You have begun ranting against an absolutist straw-man of your own creation. What I DID say is that: 1. Type-checked exceptions are just as valuable as type-checked returns. 2. The "problems" you listed with checked-exceptions are baseless: Each of them is identical to an architectural decision or task you already regularly complete for happy-path return-types. 3. The fundamental driver of complaints is that people don't like to spend time on the unhappy-path, and aren't as rewarded for it either.