These are fully equivalent in outcome, though often not low-level implementation. You can use try...catch (called panic...recover in Go) to pack a normal and abnormal return case into the equivalent of a Result<> type. Or just pass an abnormal Result<> back to the caller to manually unwind a single "layer" of the call stack.

▲

biorach 7 months ago | parent [-]

> These are fully equivalent in outcome

They are so different in DX, ergonomics, implementation and traceability that I'm not sure this is true other than in the most abstract sense

▲

sshine 7 months ago | parent [-]

There is some DX similarity between checked exceptions and Result types.

Because the compiler will fail if you don't explicitly mention each possible exception.

But checked exceptions are coming out of style: They're unchecked in C#, and frameworks like Spring Boot in Java catch all checked exceptions and rethrow them as Spring Boot flavored unchecked ones.

For unchecked exceptions and Result types:

The DX is very different in one critical way:

With Results you constantly have to differentiate between error and ok states, before you proceed. With unchecked exceptions you generally assume you're always in an ok state. It's equivalent to wrapping your whole function body in 'try { ... } catch (Exception e)'. And you can get that with Result types in Rust by using '?' and not worry about doing something half-way.

Ultimately: Are you a happy-path programmer?

▲

Arnavion 7 months ago | parent [-]

>Because the compiler will fail if you don't explicitly mention each possible exception.

But only the first time. Once you add `throws FooException` to the caller signature, the compiler won't complain about any future callees that also happen to throw FooException, even if you did care about handling their exceptions yourself. With callees that return Result you do get to make that decision for every callee.

▲

sshine 7 months ago | parent [-]

That's a fair distinction.

I would say "adding Result to the caller signature" provides a similar cascade, but it's not entirely true: Every call must separately be unwrapped. So consistently wrapping your Result calls with the '?' operator is similar to a gigantic try-catch block or adding 'throws CheckedException' everywhere.

So both the '?' operator and adding 'throws CheckedException' everywhere let you accidentally neglect proper error handling: You have a default that is syntactically almost invisible and frees you from thinking. The checked exceptions give you a little more freedom from thinking than the '?' operator.

▲

Arnavion 7 months ago | parent [-]

>So both the '?' operator and adding 'throws CheckedException' everywhere let you accidentally neglect proper error handling: You have a default that is syntactically almost invisible and frees you from thinking.

No. You're choosing to write the `?` there to bubble up the error. It's a compiler error if you forget it. Whereas with `throws FooException` you only get forced to remember it the first time, and after that you're allowed to forget it.

▲

sshine 7 months ago | parent [-]

> You're choosing to write the `?`

...but you're not choosing to write the `throws FooException`?

I can only say that if the `?` weren't around and you had to write more verbose handling each time, having the question "How should this one particular error be handled?" might come up more often and might prevent more bugs than when you can carelessly `?`-annotate your way through a dozen lines without any equivalents of `finally { ... }` anywhere.

	▲	Arnavion 7 months ago \| parent [-]
		>...but you're not choosing to write the `throws FooException`? Now read the rest of the comment after where you stopped reading. Or reread https://news.ycombinator.com/item?id=42249525 I'm tired of repeating myself.