I mean broadly that's my entire problem with errors as values: every implementation wastes a ton of syntax trying to make them like exceptions.

▲

MindSpunk 3 days ago | parent | next [-]

The common problems with exceptions isn’t the easy part of try/catch, it’s the execution model and “any function could throw” that causes most contention. Error values are logically simpler and fully document if and what errors the function can return. Checked exceptions solve that too, but in practice nobody used them even where available. And you still end up with hidden control flow with exceptions, the exceptional path through a function is syntactically invisible and difficult to audit without very strong language tooling.

	▲	marcianx 3 days ago \| parent [-]
		And also the issue with checked exceptions is that one can't be generic over the checked exception, at least in Java. So it's impossible to write out a universally useful function type that's strictly typed on the error. This definition of `ThrowingFunction` for Java [1] needs just have `throws Exception`, allowing just about anything to be thrown. Most functional-inspired languages would just have a single `f: T -> Result<U, E>` interface, which supports both (1) a specific error type `E`, which can also be an uninhabited type (e.g. never type) for an infallible operation, and (2) where `U` can be the unit type if the function doesn't return anything on success. That's about as generic as one can get with a single "interface" type. [1]: https://docs.spring.io/spring-framework/docs/current/javadoc...

▲

b_e_n_t_o_n 3 days ago | parent | prev [-]

Go unironically gets this right - you just treat them like a normal value instead of trying to make them more "ergonomic".