Rust allows you to choose whatever method you want.

• Early return propagating the error
• Early return ignoring the error (maybe by returning a default value)
• Explicit handling by if-else (or match) to distinguish between error and not error cases.
• Early return and turn the error into another type that is easier to handle by the caller.
• Assume there is no error, and just panic if there is. (.unwrap)

There are only 2 error handling methods that you cannot do:

• Exceptions
• Ignore the error and continue execution

And that is because both of them are bad because they allow you to do the second one, when .unwrap is just there and better.

If your concept of "not ugly" is "I just want to see the happy path" then you either write bad code that is "not ugly" or write good code that is "ugly". Because there is no language that allows you to handle errors while not having error handling code near where the errors are produced.

Yeah, I was gonna say, error handling easily makes up 80+% of the code paths, and depending on whether you're building a library or service or script etc., different strategies are most suitable for how to deal with those code paths.

In a script, you often just want it to crash. In a library, you want to make these code paths matchable, in case the user cares why something failed. And then you have the awkward in-between, which is that 99% of your application codebase will be used by your main-function like a library, but you don't want to spend as much effort on error handling for that as a proper library does, in particular also because you know what all consumers of your application-library need to know.

So, it's kind of multiple different problems, with overlap, and people are hoping for one easy solution to cover all these problems.