3 ms·
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 thi
by 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 agoYour 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 agoIIUC, for checked exceptions Java lacks parametric polymorphism (generics).
- kaba0 2y agoAh. But that’s also not true, you can do something like `throws T`.
- Yoric 2y agoI 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.
- kaba0 2y agoIt still can have it, see e.g. Vavr, or other functional libraries. Edit: Not sure why the downvote. This works in Java today with proper pattern matching (I left out the complete name from the permit clause, it won’t compile as is): sealed interface <T,E> Result permits Ok, Error { record Ok(T val) implements Result<T,E> {} record Error(E err) implements Result<T,E> {} }
- Yoric 2y ago> 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. For what it's worth, checked errors have been part of the ML family of languages (some of the immediate ancestors of Rust) since pretty much forever and of LISP even longer. Still, let's give credit where it's due: very few people used them before Java.