4 ms·

I don't think you can lump Java with the others in this comparison, the checked exceptions in Java make it different. Specifically this: > Function signatures

I don't think you can lump Java with the others in this comparison, the checked exceptions in Java make it different. Specifically this: > Function signatures do not contain errors. Does not apply to checked exceptions in Java. The possible exceptions thrown are definitely part of the function signature and matter when implementing/overriding/etc. Also I really dislike phrases like this in these sorts of comparisons: > thus better suited to seasoned developers. It's a real oversimplification, and can be interpreted as an insult on issues like this where there genuinely are advantages to either approach. More often than not, these statements imply you see yourself as one of those "seasoned developers". And you'd better be damn sure you got everything right if you start self-labelling like that.

brabel 2y ago
You're completely right. Here's the example function signature from the blog post: fn greet() (string) (error) In Java, you can write exactly the same thing: String greet() throws Error The "implicit error propagation also looks exactly the same. fn main() () (error) { s := greet() // <-- Implicit error propagation println(s) } In Java: void main() throws Error { var s = greet(); // <-- Implicit error propagation System.out.println(s); } The case with a question mark after the error is the only case not covered by Java. The final case, with explicit error handling: fn main() { s := greet() // <-- failure result can not be propagated println(s) } Also looks exactly the same in Java: void main() { var s = greet(); // <-- compilation error: must handle Error } EDIT: ok, let's mention also RuntimeException! In Java, you don't need to declare those (and subtypes) in your signature (but you can) and even if you do, you don't need to handle them. That's because the original idea was that RuntimeException was to represent programmer mistakes that should never be caught. The Java community ended up using it exactly the opposite way because everyone complained about explicit error handling being too much of a chore, so making most Exceptions subtype RuntimeException became common so now you can't assume that you don't need to catch them (but the compiler won't force you to)... other JVM languages like Groovy and Kotlin just eliminated checked Exceptions completely for that reason. It's a bit amusing to me how "checked errors" in general has made a comeback in Go and Rust, and in many newer languages like Zig (and now this one) as well. I think that the way Rust does it seems to be the best "compromise". It's almost like Java's checked Exceptions, but it's added sugar on top to make it much easier, while still explicit, to propagate errors. It's a tiny difference , but it seems that tiny difference makes ALL the difference for people (just see how people love Rust and its error handling, but loathe Java's). Oracle guideline: https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html https://docs.oracle.com/javase/tutorial/essential/exceptions...
- deleted 2y ago
  [deleted]
- lucianbr 2y ago
  Your analysis is spot-on.
- marcosdumay 2y ago
  > It's a bit amusing to me how "checked errors" in general has made a comeback in Go and Rust Go is... well, Go. On other languages, it came back because they have polymorphism on the error type. Java is a huge mess because it has no implicit types nor most instances of polymorphism.
  - kaba0 2y ago
    > Java is a huge mess because it has no implicit types nor most instances of polymorphism Heh? What instance of polymorphism does it lack? Also, depending on what you mean by implicit types, Java has type inference nowadays.
    - dllthomas 2y ago
      IIUC, for checked exceptions Java lacks parametric polymorphism (generics).
      - kaba0 2y ago
        Ah. But that’s also not true, you can do something like `throws T`.
        Yoric 2y ago
        I assume that the poster meant that Java could have had `Result<T, E>` return values like Rust if it had launched with parametric polymorphism, instead of having a layer of the type system dedicated to errors.
zupa-hu 2y ago
> I don't think you can lump Java with the others in this comparison Fair point, I've removed Java from the examples. Apologies, I haven't used Java for ages and relied on my memories. That said, I understand they are not used much in practice because changing a checked exception's type is a refactoring nightmare. Or are they? > Also I really dislike phrases like this [...] Okay, help me do better, what about citizen developers? I mean the kind of person who explicitly never wants to be a developer, yet there s/he is developing a program. I called them novice in this page, and the people I have in mind would not be offended at all. And yes, compared to them, someone with a computer science background and 10 years of coding experience is a seasoned developer. Open to suggestions.

brabel 2y ago

You're completely right. Here's the example function signature from the blog post: fn greet() (string) (error) In Java, you can write exactly the same thing: String greet() throws Error The "implicit error propagation also looks exactly the same. fn main() () (error) { s := greet() // <-- Implicit error propagation println(s) } In Java: void main() throws Error { var s = greet(); // <-- Implicit error propagation System.out.println(s); } The case with a question mark after the error is the only case not covered by Java. The final case, with explicit error handling: fn main() { s := greet() // <-- failure result can not be propagated println(s) } Also looks exactly the same in Java: void main() { var s = greet(); // <-- compilation error: must handle Error } EDIT: ok, let's mention also RuntimeException! In Java, you don't need to declare those (and subtypes) in your signature (but you can) and even if you do, you don't need to handle them. That's because the original idea was that RuntimeException was to represent programmer mistakes that should never be caught. The Java community ended up using it exactly the opposite way because everyone complained about explicit error handling being too much of a chore, so making most Exceptions subtype RuntimeException became common so now you can't assume that you don't need to catch them (but the compiler won't force you to)... other JVM languages like Groovy and Kotlin just eliminated checked Exceptions completely for that reason. It's a bit amusing to me how "checked errors" in general has made a comeback in Go and Rust, and in many newer languages like Zig (and now this one) as well. I think that the way Rust does it seems to be the best "compromise". It's almost like Java's checked Exceptions, but it's added sugar on top to make it much easier, while still explicit, to propagate errors. It's a tiny difference , but it seems that tiny difference makes ALL the difference for people (just see how people love Rust and its error handling, but loathe Java's). Oracle guideline: https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html https://docs.oracle.com/javase/tutorial/essential/exceptions...

deleted 2y ago
[deleted]
lucianbr 2y ago
Your analysis is spot-on.
marcosdumay 2y ago
> It's a bit amusing to me how "checked errors" in general has made a comeback in Go and Rust Go is... well, Go. On other languages, it came back because they have polymorphism on the error type. Java is a huge mess because it has no implicit types nor most instances of polymorphism.
- kaba0 2y ago
  > Java is a huge mess because it has no implicit types nor most instances of polymorphism Heh? What instance of polymorphism does it lack? Also, depending on what you mean by implicit types, Java has type inference nowadays.
  - dllthomas 2y ago
    IIUC, for checked exceptions Java lacks parametric polymorphism (generics).
    - kaba0 2y ago
      Ah. But that’s also not true, you can do something like `throws T`.
      - Yoric 2y ago
        I assume that the poster meant that Java could have had `Result<T, E>` return values like Rust if it had launched with parametric polymorphism, instead of having a layer of the type system dedicated to errors.

zupa-hu 2y ago

> I don't think you can lump Java with the others in this comparison Fair point, I've removed Java from the examples. Apologies, I haven't used Java for ages and relied on my memories. That said, I understand they are not used much in practice because changing a checked exception's type is a refactoring nightmare. Or are they? > Also I really dislike phrases like this [...] Okay, help me do better, what about citizen developers? I mean the kind of person who explicitly never wants to be a developer, yet there s/he is developing a program. I called them novice in this page, and the people I have in mind would not be offended at all. And yes, compared to them, someone with a computer science background and 10 years of coding experience is a seasoned developer. Open to suggestions.