> it's objectively better on every metric except familiarity
I find that as a rule, people who throw around the word "objectively" a lot tend to dramatically overestimate how much they know, usually because they're advanced beginners in the domain that they're so confident in and haven't yet run into the complexity of real-world implementation.
There are very few features in programming languages that can be described as "objectively" better or worse than other features. The whole discipline is more art than science, and the only practitioners who actually accomplish anything meaningful in their work are the ones who acknowledge the inherent subjectivity of most of programming language design.
Programming languages do not exist in a vacuum, they exist in an ecosystem of interrelated individuals and technology. Do not be so quick to dismiss the weight of generations of programmers and billions of lines of code as people just being "stuck in the 90s".
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.
Normally I'd agree with you, but this really is not a matter of opinion, it's up there with eg compiler built in null safety is superior to everything being able to be null. There's plenty of people who think it's not, and who come up with all kinds of bizarre reasons to say so, it's just that they're wrong. Even the Java language designers themselves (including people like Bloch and Goetz) have for decades been talking and writing books about how wrong Java got a lot of things. But the community is stuck in its ways and wants to keep coding like they always have.
> Even the Java language designers themselves (including people like Bloch and Goetz) have for decades been talking and writing books about how wrong Java got a lot of things.
Can you please provide a citation, with a link, for where Bloch or Goetz said that checked exceptions are something Java got wrong?
Effective Java has a lot to say about exceptions, and does encourage avoiding them where possible, but you have to really be cherry picking to read it as Bloch saying to never use checked exceptions when the 2017 edition says this:
> The cardinal rule in deciding whether to use a checked or an unchecked
exception is this: use checked exceptions for conditions from which the caller
can reasonably be expected to recover. By throwing a checked exception, you
force the caller to handle the exception in a catch clause or to propagate it
outward. Each checked exception that a method is declared to throw is therefore a potent indication to the API user that the associated condition is a possible
outcome of invoking the method.
And this:
> Many Java programmers dislike checked exceptions, but used properly, they can
improve APIs and programs. Unlike return codes and unchecked exceptions, they
force programmers to deal with problems, enhancing reliability.
Bloch advocates against overuse of exceptions, which is fair, but his reasoning applies equally well to overuse of Result: if you can use the type system to prevent an invalid value from being passed in, do so!
As for Goetz, this is the most recent commentary I can find from him on checked exceptions [0]:
> If people are not forced to document what errors their code throws, they won't -- especially the people that the people in camp (3) are afraid of. As long as those folks are allowed to code, the value we get from checked exceptions forcing developers to document failure modes overwhelms the annoyances.
> But, as I said above, I think many of the annoyances can be removed by adding a small number of exception streamlining constructs. This doesn't help Neal with simplifying closures, but it does help us get our job done with a little less pain.
> Finally, a meta-note -- its really easy to misinterpret the volume of support for "removing checked exceptions" as any sort of gauge for community consensus. We're intimately familiar with the pain that checked exceptions cause; we're substantially less familiar with the pain that they free us from. (Obviously, neither approach is perfect, otherwise there'd be no debate.)
I was referring to how Bloch and Goetz have tried to tell Java devs for decades to avoid null, mutation and just in general the traditional Java coding style, with little success.
As for exceptions, it's hilarious that they and the Java community in general are still stuck on arguing about checked vs unchecked exceptions. That's my whole point - you can argue about that forever and you will always be wrong, because exceptions are a failed experiment and will never work or reach a consensus. Move past it.
I really, REALLY don't understand what's so wrong with just.. making methods return what they say they do, as plain objects. The antagonism towards doing so is literally just ingrained culture with zero sensible justification.
> I really, REALLY don't understand what's so wrong with just.. making methods return what they say they do, as plain objects. The antagonism towards doing so is literally just ingrained culture with zero sensible justification.
From experience with Rust, a major concern is lack of stack traces in error messages. Rust has libraries that built up around Result to address this (like Anyhow), but by the time you've included Anyhow with stack traces enabled you've basically reinvented checked exceptions in Result types. For Rust this is probably more ergonomic than introducing exceptions into the language, but Java already has checked exceptions that work like Anyhow does out of the box.
That's the part that you seem to be missing: checked exceptions are nearly identical semantically to result types, and they already exist and are widely used in the language. There are a few minor ergonomic problems that discourage their wider use, but it makes way more sense for Java to fix those than for people to migrate to Result types, which are not nearly as ergonomic in Java as they are in Rust or similar.
You tried to address this upthread, but it was frankly a pretty bad strawman that contrasted a horrible example of checked exceptions with an idealized example of a Result type. You then compounded the strawman with a double standard by demanding that the checked exceptions example immediately account for what would happen in the catch block while hand-waving away the handling of Left values in the Result type as something that we can deal with at some unspecified later time.
Dealing with failures later at the edges of the system is the reason why exceptions were invented, so it's highly disingenuous to claim that as a capability unique to Result types.
> by the time you've included Anyhow with stack traces enabled you've basically reinvented checked exceptions in Result types
If the error is wrapped into an `anyhow::Error`, and the result in `anyhow::Result<T>`, it has less information than checked exceptions. Coz the type now only tells you the call can fail, but not how (it's anyhow!).
> That's the part that you seem to be missing: checked exceptions are nearly identical semantically to result types
I find that as a rule, people who throw around the word "objectively" a lot tend to dramatically overestimate how much they know, usually because they're advanced beginners in the domain that they're so confident in and haven't yet run into the complexity of real-world implementation.
There are very few features in programming languages that can be described as "objectively" better or worse than other features. The whole discipline is more art than science, and the only practitioners who actually accomplish anything meaningful in their work are the ones who acknowledge the inherent subjectivity of most of programming language design.
Programming languages do not exist in a vacuum, they exist in an ecosystem of interrelated individuals and technology. Do not be so quick to dismiss the weight of generations of programmers and billions of lines of code as people just being "stuck in the 90s".