4 ms·

> I don't think checked exceptions are one of them While they may not have been the wrong decision, empirical evidence continually shows they add a syntactical

> I don't think checked exceptions are one of them While they may not have been the wrong decision, empirical evidence continually shows they add a syntactical burden many devs just work around (e.g. just wrap in a RuntimeException anyways). It's understandable why most modern languages don't consider predictable exceptions as part of the function signatures (though many discourage exceptions altogether in all but the most extreme cases).

hota_mazi 8y ago
This is similar to saying that since error codes are ignored by most developers, functions shouldn't bother returning them at all. Error conditions captured in the type system are a vital part of making code robust. The fact that some developers don't know how to properly handle these error cases doesn't change anything to the soundness of checked exceptions.
- kodablah 8y ago
  > This is similar to saying that since error codes are ignored by most developers, functions shouldn't bother returning them at all. It's not like saying they shouldn't return them (unchecked exceptions exist), it's like saying they shouldn't be forced to check the error code or declare that they will return that error code themselves. Checked exceptions aren't sound when in practice the same ones are reused to mean many things. And we shouldn't pretend deciding whether an exception should or shouldn't be checked is an objective choice applied the same way across the ecosystem.
  - hota_mazi 8y ago
    Checked exceptions are the compiler forcing the developer to consider error cases. What's not to like about that? Contrast with all the other approaches (runtime exceptions, return codes, Either/Result, etc...) where the developer can happily ignore errors, the code will compile, and then crash at runtime.
    - erik_seaberg 8y ago
      I'd be happier with checked exceptions if Java assumed that list.stream().map(doStuff) might throw whatever doStuff might throw, but instead map is defined so that doStuff can never throw any checked exception, which requires smuggling out every real-world failure mode.
iSnow 8y ago
And while we are at it, @SneakyThrows by Lombok.

hota_mazi 8y ago

This is similar to saying that since error codes are ignored by most developers, functions shouldn't bother returning them at all. Error conditions captured in the type system are a vital part of making code robust. The fact that some developers don't know how to properly handle these error cases doesn't change anything to the soundness of checked exceptions.

kodablah 8y ago
> This is similar to saying that since error codes are ignored by most developers, functions shouldn't bother returning them at all. It's not like saying they shouldn't return them (unchecked exceptions exist), it's like saying they shouldn't be forced to check the error code or declare that they will return that error code themselves. Checked exceptions aren't sound when in practice the same ones are reused to mean many things. And we shouldn't pretend deciding whether an exception should or shouldn't be checked is an objective choice applied the same way across the ecosystem.
- hota_mazi 8y ago
  Checked exceptions are the compiler forcing the developer to consider error cases. What's not to like about that? Contrast with all the other approaches (runtime exceptions, return codes, Either/Result, etc...) where the developer can happily ignore errors, the code will compile, and then crash at runtime.
  - erik_seaberg 8y ago
    I'd be happier with checked exceptions if Java assumed that list.stream().map(doStuff) might throw whatever doStuff might throw, but instead map is defined so that doStuff can never throw any checked exception, which requires smuggling out every real-world failure mode.

iSnow 8y ago

And while we are at it, @SneakyThrows by Lombok.