4 ms·

> the weight of generations of programmers and billions of lines of code as people just being "stuck in the 90s". The weight of generations of programmers and

by mrkeen 3y ago

> the weight of generations of programmers and billions of lines of code as people just being "stuck in the 90s". The weight of generations of programmers and billions of lines of code have come to the conclusion that: 1) Functions should declare/document what they return (including failure modes) 2) Checked exceptions are not worth it These are mutually exclusive. Result types genuinely are better.

lolinder 3y ago
I'm a fan of Result types in languages that incorporated them as part of the design (say, Rust), but I'm not convinced that they're the right answer for Java. Result types only really make sense in a highly expression-oriented language, and while Java has taken important steps in that direction it's really not there yet and likely never will be. I think a more fruitful path of exploration is improvements to the ergonomics of checked exceptions. Semantically there really is very little difference between checked exceptions and Result types (OP's argument to the contrary is a straw man and proves nothing), the main reason why people fought their use in the early days of Java was that the ergonomics were pretty poor. I suspect that there are a few tweaks that could be made with modern PL techniques that would make checked exceptions feel more comfortable (analogous to the addition of ? in Rust), and since they've been baked into the language for decades now through thousands of existing libraries the returns from making them easier to use will be much higher than the returns from creating a new "standard" way to handle errors in Java.
wiseowise 3y ago
> Result types genuinely are better. Only if there’s a language support for them. Like Rust, where I can concisely drop out of function if it’s an error case. https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/std/result/index.html#the-question-mark-operator- https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/sh... If I have to constantly write when(result) { Ok -> … Err -> … } then checked exceptions and throws clause are better.

by mrkeen 3y ago

lolinder 3y ago

I'm a fan of Result types in languages that incorporated them as part of the design (say, Rust), but I'm not convinced that they're the right answer for Java. Result types only really make sense in a highly expression-oriented language, and while Java has taken important steps in that direction it's really not there yet and likely never will be. I think a more fruitful path of exploration is improvements to the ergonomics of checked exceptions. Semantically there really is very little difference between checked exceptions and Result types (OP's argument to the contrary is a straw man and proves nothing), the main reason why people fought their use in the early days of Java was that the ergonomics were pretty poor. I suspect that there are a few tweaks that could be made with modern PL techniques that would make checked exceptions feel more comfortable (analogous to the addition of ? in Rust), and since they've been baked into the language for decades now through thousands of existing libraries the returns from making them easier to use will be much higher than the returns from creating a new "standard" way to handle errors in Java.

wiseowise 3y ago

> Result types genuinely are better. Only if there’s a language support for them. Like Rust, where I can concisely drop out of function if it’s an error case. https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/std/result/index.html#the-question-mark-operator- https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/sh... If I have to constantly write when(result) { Ok -> … Err -> … } then checked exceptions and throws clause are better.