5 ms·

This just feels like recreating exceptions, but with more complicated syntax.

XorNot 1y ago
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 1y ago
  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 1y ago
    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-api/org/springframework/util/function/ThrowingFunction.html https://docs.spring.io/spring-framework/docs/current/javadoc...
- b_e_n_t_o_n 1y ago
  Go unironically gets this right - you just treat them like a normal value instead of trying to make them more "ergonomic".
catlifeonmars 1y ago
Sometimes it’s nice to have one control flow mechanism rather than too. One could argue that traditional exceptions are more complicated with a their alternative control flow and syntax.
IshKebab 1y ago
Yeah but only if you were to always use checked exceptions, and have mandatory try/catch around every function call, and have a much nicer syntax for throwing exceptions with added context. I've never seen any language that did that but I guess it would be possible.

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 1y ago
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 1y ago
  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-api/org/springframework/util/function/ThrowingFunction.html https://docs.spring.io/spring-framework/docs/current/javadoc...
b_e_n_t_o_n 1y ago
Go unironically gets this right - you just treat them like a normal value instead of trying to make them more "ergonomic".

catlifeonmars 1y ago

Sometimes it’s nice to have one control flow mechanism rather than too. One could argue that traditional exceptions are more complicated with a their alternative control flow and syntax.

IshKebab 1y ago

Yeah but only if you were to always use checked exceptions, and have mandatory try/catch around every function call, and have a much nicer syntax for throwing exceptions with added context. I've never seen any language that did that but I guess it would be possible.