Short answer: It is too easy to just "try catch swallow" everything in java*. Where in Rust and Go, it's much easier to just write good error control code 'correctly', and make it hard to do poorly. i.e., "Falling into the pit of success" programming paradigm.
I strongly suggest you read Joe Duffy's blog on error handling strategies, ...
There are some good points made in other answers, but I feel each picks out a different aspect, so I'm going to try to bring them together.
Checked vs unchecked errors
The idea of statically checking code is to make "bad" programs impossible to write. In other words, it places constraints on what the programmer can do. Those constraints have a ...
The problem with using always the return value approach is that often the developers end up mixing business logic and error handling.
Beyond return values, error handling could be about:
Resource handling, closing access to files or database connections, even though this point was later addressed with the construct try/with resource
Transaction handling. ...
checked exceptions can be seen as syntactic sugar for alternative return values
This is the modern perspective on this language feature, but the feature was initially intended and used for a different purpose, at which it failed.
Checked exceptions were added to the Java language before its initial release back in 1996. Back then, Java aspired to be a more ...
Disclaimer: This will, to a degree, be my own personal take on the problem. I love programming language design, I've thought, read, and discussed a lot of about PL design in general, and the hard topic of errors in particular. This gives me some experience, and also an appreciation that beyond objective factors, there is a lot of subjectivity at play. I will ...
The type winds up being T with a type union of A, B, C.
This is an odd type that doesn't work best with other things, for example
There isn't a good way to do a generic with variadic check exception.
In Java, every exception must extend Throwable with a stack trace.
You could invent solutions to these, and you'd likely wind ...
Checked exceptions can't be treated as just another part of the expression. They must be handled out of line.
With an error return value, you can write a function that converts error values to a default value, for example. Something like this (even if the variant type has no getOrDefault method):
There are three parts to error code:
Code that generates the errors.
Code that handles the errors.
Code that just propagates the errors from part 1 to part 2.
Most programmers don't give part 3 much thought, because most "enterprise" languages use unchecked exceptions where the part 3 code is essentially invisible. In error propagating code, you ...
From a scientific point of view, checked exceptions can be seen as alternative return values, e.g.
Exactly. They can be seen that way, and they should be but they aren't.
Using an Error type like is common in Rust, Elm, Haskell, and in some sub-communities in Scala or a special error value as in Go is just an alternative return value indicated in the type ...
If I place an order an item from a website and I can see in my online banking that my payment has gone through and the website still says "Payment is pending", I'm not likely to walk away. I'm also not likely to retry the order, since I have no idea that you're using an idempotent payment process. I'm far more likely to contact your support ...
Consider unwinding the idempotent transaction to the pre-buy state or a "may try again" state on error. This leaves you with two or three terminal states to handle (in total).
By doing this you can also safely reuse the id. Reusing the id preserves the duplicate prevention benefits of the idempotent approach.
You may discover that reliably ...
It depends on what you tell the user.
If you tell the user it failed you’re done until the user resubmits. Which could be done with a single click.
If you tell the user to wait you can simply keep them waiting while you resubmit. You could make this seamless or you can keep them updated by explaining the delay.
Automatically trying again after announcing a ...