3 ms·

The problem with checked exceptions is that any method can throw runtime exceptions, whether it declares checked exceptions or not. So the presence or absence o

The problem with checked exceptions is that any method can throw runtime exceptions, whether it declares checked exceptions or not. So the presence or absence of "throws" does not really change your approach to error handling. An exception might happen either way, so you need to exercise the same level of care either way. Furthermore, checked exceptions force you to bubble up implementation details all the way up to the interfaces. For example, if any implementation of an interface might throw IOException, you need to put that in the method signature in the interface. You can be clever and wrap it in a custom exception that exposes the same level of abstraction as the interface, but that's not a whole lot better than just using RuntimeException, and it causes people to try to cast the exception cause.

Terr_ 8y ago
Your second paragraph has a direct-equivalence to complaining about return-types and advocating that everybody should just specify "Object" to make things easier. ( https://imgur.com/iYE5nLA https://imgur.com/iYE5nLA ) In both cases it's about constraining and describing the results from a method. The only difference is that most developers are so much more accustomed to thinking and coding along the happy-path, where they will willingly do all the exact same architectural tasks. Seriously, read these three variations aloud and see how they sound: >> return-types force you to bubble up implementation details all the way up to the interfaces >> if any implementation of an interface might return Foo, you need to put that in the method signature in the interface >> You can be clever and wrap it in a custom return-type that exposes the same level of abstraction as the interface, but that's not a whole lot better than just using Object I'm willing to bet you can think of a slightly-incredulous answer to each of those, right? Perhaps something along the lines of "no they don't", "yes that's normal" and "WTF of course you should."
- 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.

Terr_ 8y ago

Your second paragraph has a direct-equivalence to complaining about return-types and advocating that everybody should just specify "Object" to make things easier. ( https://imgur.com/iYE5nLA https://imgur.com/iYE5nLA ) In both cases it's about constraining and describing the results from a method. The only difference is that most developers are so much more accustomed to thinking and coding along the happy-path, where they will willingly do all the exact same architectural tasks. Seriously, read these three variations aloud and see how they sound: >> return-types force you to bubble up implementation details all the way up to the interfaces >> if any implementation of an interface might return Foo, you need to put that in the method signature in the interface >> You can be clever and wrap it in a custom return-type that exposes the same level of abstraction as the interface, but that's not a whole lot better than just using Object I'm willing to bet you can think of a slightly-incredulous answer to each of those, right? Perhaps something along the lines of "no they don't", "yes that's normal" and "WTF of course you should."

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.