6 ms·

Right, and that's why Java introduced checked exceptions in 1.0. A feature which wasn't proven back then and remains unproven now. Another example being overen

Right, and that's why Java introduced checked exceptions in 1.0. A feature which wasn't proven back then and remains unproven now. Another example being overengineered streams. Parallel streams look really cool as a demo, but have been proven dangerous in their default configuration (they can exhaust the default thread pool).

deleted 4y ago
[deleted]
kaba0 4y ago
Checked exceptions are exact analogs to Result types, but better (auto-unwrap, bubble up, stack traces). It is unfortunately far from flawless (inheritance is not a great combo with it), but that has been part of the language since the beginnings. Streams are not a language feature, it is only a library. And I honestly don’t find them over-engineered, they really make plenty of logics very readable.
- lenkite 4y ago
  Pity that the Streams functions don't support checked exceptions.
  - Quekid5 4y ago
    It's the only sane way. Checked exceptions were a fundamental mistake which basically makes it impossible to actually use (non-RuntimeException derived) exceptions reliably for their intended purpose. As soon as you introduce any higher-order programming (e.g. functions that take other functions as parameters) you start to have to wrap e.g. IOException... but that means that calling code can no longer catch that wrapped IOException via a simple "catch (IOException e) { ... }"... it instead has to catch whatever you wrapped that exception in... and manually look inside that Throwable's suppressedExceptions list. And so you end up with stuff like Guava's Throwables utility methods. Of course, this probably happened because Java basically didn't have much in the way of higher-order constructs at the start, so they didn't notice that they were painting themselves into a corner... If they had a more powerful type system something usable might be possible, but as of Java right now, it just hopelessly broken. I'd suggest that a fix to the langauge would be to simply change all exceptions to unchecked, but unfortunately that might break a lot of code where the above workaround has already been implemented once consumed libraries switch away from wrapping. (Note that it's only Java-the-language which has checked exceptions. The JVM doesn't and Scala/Kotlin are much the better for it.) EDIT: The JVM is a marvel of engineering. Java... not so much.
    - pron 4y ago
      > Of course, this probably happened because Java basically didn't have much in the way of higher-order constructs at the start, so they didn't notice that they were painting themselves into a corner... The problem is generifying over checked exceptions (i.e. parametric polymorphism over checked exceptions), and there's actually an elegant solution that's been long known -- so the "corner" was well-noticed, as well as the means to get out of it -- but that requires laying some groundwork first which wasn't done because the ground wasn't ready, but it's getting there, so stay tuned. > The JVM is a marvel of engineering. Java... not so much. This was James Gosling's stated strategy and one of the secrets of Java's exceptionally-long-lasting success. While many developers like feature-rich, sophisticated languages, the vast majority of them really, really don't (although they are underrepresented on HN, certainly when it comes to language feature discussions). Many of the things people need can be hidden in the runtime, wrapped by a conservative, non-threatening language. Gosling called that "a wolf in sheep's clothing." See the first half of this talk by Brian Goetz on this very subject: https://youtu.be/Dq2WQuWVrgQ https://youtu.be/Dq2WQuWVrgQ
      - ackfoobar 4y ago
        > it's getting there, so stay tuned It's nice to see from a theoretical perspective. But my impression is that the ecosystem is moving towards having no checked exception. What will happen to the existing code when generics works with union typed checked exceptions?
      - Quekid5 4y ago
        > The problem is generifying over checked exceptions (i.e. parametric polymorphism over checked exceptions), and there's actually an elegant solution that's been long known -- so the "corner" was well-noticed, as well as the means to get out of it -- but that requires laying some groundwork first which wasn't done because the ground wasn't ready, but it's getting there, so stay tuned. Happy to hear something might be getting done about it, but users have suffered for 20+ years. I'm probably not going back to Java anyway :). Any technical details you can share about a potential redesign? AFAICT checked-exception-like-things will always be at odds with the variance requirements on method signatures, so I'm a bit curious. (Outside of the natural solutions where variance isn't a problem, e.g. polymorphic variants or row types.) Regardless, I'm waaay more interested in the JVM-level improvements that you & co. have been doing! Kudos! Btw, any inside tips on TCO? ;) > [Gosling] I have seen that talk, and I largely agree with the philosophy (assuming the goal is correct), but in this particular case, I think it was a mistake to let the problems fester for 20+ years rather than just admitting defeat and removing the checked-ness. If it's going to take that long to implement a solution to a constant pain point... the solution might as well not exist. (Perfect = enemy of good and all that.) EDIT: Just to add: I definitely don't mean to cast aspersions on anybody in the Java language design team or anything like that -- if that's how my original comment came across. Everybody makes mistakes and predicting the future is hard at the best of times :). I just wish they'd reevaluated some things along the way...
  - deleted 4y ago
    [deleted]
- tialaramex 4y ago
  Exceptions have implied control flow which makes them strictly worse than the Result types which are, as their name suggests, just types. Imagine if some other common types had unrelated features like this baked into them. Want a string? Sorry in my new language all the strings need their own separate thread for some reason. Actually sorry, I forgot, we're in a Java topic, Java actually did have features baked into types. All of Java's user defined types insisted on living on the heap. Just want to make a pair of integers? Sorry, that's an Object now and so it lives on the heap, whereas just one integer is fine, those are just local stack variables. Did they fix that yet?
  - mixedCase 4y ago
    Checked exceptions are explicit. They are no weirder than doing do-notation in an Either monad, the syntax could be more ergonomic but they are clear as day.
  - rotifer 4y ago
    Regarding user-defined types, probably what you're looking for is JEP 401: Primitive Classes (Preview) [1]. I believe it's currently being worked on. [1] https://openjdk.org/jeps/401 https://openjdk.org/jeps/401
  - coldtea 4y ago
    >Exceptions have implied control flow which makes them strictly worse than the Result types which are, as their name suggests, just types. If they're checked exceptions, then the control flow is hardly "implied". If anything, it's explicit: this method potentially throws X, so if X is raised, expect this control flow consequence.
    - woodruffw 4y ago
      I think the "implied" part is in the callsite ambiguity: a Java method marked with "throws X" can raise X at any callsite in its method body, whereas a Rust function of type `Result<...>` has each `Err` variant marked either directly with a return or with the `?` sugar.
coldtea 4y ago
I, for one, like checked exceptions.
- peterashford 4y ago
  Me too. Error handling is a problem that programming languages still struggle with (witness Golang). But IMO Java does it really well.

deleted 4y ago

[deleted]

kaba0 4y ago

Checked exceptions are exact analogs to Result types, but better (auto-unwrap, bubble up, stack traces). It is unfortunately far from flawless (inheritance is not a great combo with it), but that has been part of the language since the beginnings. Streams are not a language feature, it is only a library. And I honestly don’t find them over-engineered, they really make plenty of logics very readable.

lenkite 4y ago
Pity that the Streams functions don't support checked exceptions.
- Quekid5 4y ago
  It's the only sane way. Checked exceptions were a fundamental mistake which basically makes it impossible to actually use (non-RuntimeException derived) exceptions reliably for their intended purpose. As soon as you introduce any higher-order programming (e.g. functions that take other functions as parameters) you start to have to wrap e.g. IOException... but that means that calling code can no longer catch that wrapped IOException via a simple "catch (IOException e) { ... }"... it instead has to catch whatever you wrapped that exception in... and manually look inside that Throwable's suppressedExceptions list. And so you end up with stuff like Guava's Throwables utility methods. Of course, this probably happened because Java basically didn't have much in the way of higher-order constructs at the start, so they didn't notice that they were painting themselves into a corner... If they had a more powerful type system something usable might be possible, but as of Java right now, it just hopelessly broken. I'd suggest that a fix to the langauge would be to simply change all exceptions to unchecked, but unfortunately that might break a lot of code where the above workaround has already been implemented once consumed libraries switch away from wrapping. (Note that it's only Java-the-language which has checked exceptions. The JVM doesn't and Scala/Kotlin are much the better for it.) EDIT: The JVM is a marvel of engineering. Java... not so much.
  - pron 4y ago
    > Of course, this probably happened because Java basically didn't have much in the way of higher-order constructs at the start, so they didn't notice that they were painting themselves into a corner... The problem is generifying over checked exceptions (i.e. parametric polymorphism over checked exceptions), and there's actually an elegant solution that's been long known -- so the "corner" was well-noticed, as well as the means to get out of it -- but that requires laying some groundwork first which wasn't done because the ground wasn't ready, but it's getting there, so stay tuned. > The JVM is a marvel of engineering. Java... not so much. This was James Gosling's stated strategy and one of the secrets of Java's exceptionally-long-lasting success. While many developers like feature-rich, sophisticated languages, the vast majority of them really, really don't (although they are underrepresented on HN, certainly when it comes to language feature discussions). Many of the things people need can be hidden in the runtime, wrapped by a conservative, non-threatening language. Gosling called that "a wolf in sheep's clothing." See the first half of this talk by Brian Goetz on this very subject: https://youtu.be/Dq2WQuWVrgQ https://youtu.be/Dq2WQuWVrgQ
    - ackfoobar 4y ago
      > it's getting there, so stay tuned It's nice to see from a theoretical perspective. But my impression is that the ecosystem is moving towards having no checked exception. What will happen to the existing code when generics works with union typed checked exceptions?
    - Quekid5 4y ago
      > The problem is generifying over checked exceptions (i.e. parametric polymorphism over checked exceptions), and there's actually an elegant solution that's been long known -- so the "corner" was well-noticed, as well as the means to get out of it -- but that requires laying some groundwork first which wasn't done because the ground wasn't ready, but it's getting there, so stay tuned. Happy to hear something might be getting done about it, but users have suffered for 20+ years. I'm probably not going back to Java anyway :). Any technical details you can share about a potential redesign? AFAICT checked-exception-like-things will always be at odds with the variance requirements on method signatures, so I'm a bit curious. (Outside of the natural solutions where variance isn't a problem, e.g. polymorphic variants or row types.) Regardless, I'm waaay more interested in the JVM-level improvements that you & co. have been doing! Kudos! Btw, any inside tips on TCO? ;) > [Gosling] I have seen that talk, and I largely agree with the philosophy (assuming the goal is correct), but in this particular case, I think it was a mistake to let the problems fester for 20+ years rather than just admitting defeat and removing the checked-ness. If it's going to take that long to implement a solution to a constant pain point... the solution might as well not exist. (Perfect = enemy of good and all that.) EDIT: Just to add: I definitely don't mean to cast aspersions on anybody in the Java language design team or anything like that -- if that's how my original comment came across. Everybody makes mistakes and predicting the future is hard at the best of times :). I just wish they'd reevaluated some things along the way...
- deleted 4y ago
  [deleted]
tialaramex 4y ago
Exceptions have implied control flow which makes them strictly worse than the Result types which are, as their name suggests, just types. Imagine if some other common types had unrelated features like this baked into them. Want a string? Sorry in my new language all the strings need their own separate thread for some reason. Actually sorry, I forgot, we're in a Java topic, Java actually did have features baked into types. All of Java's user defined types insisted on living on the heap. Just want to make a pair of integers? Sorry, that's an Object now and so it lives on the heap, whereas just one integer is fine, those are just local stack variables. Did they fix that yet?
- mixedCase 4y ago
  Checked exceptions are explicit. They are no weirder than doing do-notation in an Either monad, the syntax could be more ergonomic but they are clear as day.
- rotifer 4y ago
  Regarding user-defined types, probably what you're looking for is JEP 401: Primitive Classes (Preview) [1]. I believe it's currently being worked on. [1] https://openjdk.org/jeps/401 https://openjdk.org/jeps/401
- coldtea 4y ago
  >Exceptions have implied control flow which makes them strictly worse than the Result types which are, as their name suggests, just types. If they're checked exceptions, then the control flow is hardly "implied". If anything, it's explicit: this method potentially throws X, so if X is raised, expect this control flow consequence.
  - woodruffw 4y ago
    I think the "implied" part is in the callsite ambiguity: a Java method marked with "throws X" can raise X at any callsite in its method body, whereas a Rust function of type `Result<...>` has each `Err` variant marked either directly with a return or with the `?` sugar.

coldtea 4y ago

I, for one, like checked exceptions.

peterashford 4y ago
Me too. Error handling is a problem that programming languages still struggle with (witness Golang). But IMO Java does it really well.