3 ms·
Something like: x := FallibleFunction() ? err -> return fmt.Errorf("something happened %v", err) Doesn't really change that, but significantly reduces the
by thayne 1y ago
Something like:
x := FallibleFunction() ? err -> return fmt.Errorf("something happened %v", err)
Doesn't really change that, but significantly reduces the amount of noise from error handling boilerplate. And (most importantly to me) reduces the amount of vertical space taken up by error handling code, which makes it easier to follow the happy flow.
- RVuRnvbM2e 1y agoReduces the vertical space by vastly increasing the horizontal space and inserting line noise into the syntax. I don't even understand what that code would do.
- deleted 1y ago[deleted]
- danenania 1y agoI think the issue is that "easier to follow the happy flow" basically also implies "easier to ignore the unhappy flow", and this is what a lot of people who have come to like Go's approach react against. We like that the error case takes up space—it's as important to deal with correctly as the happy path, so why shouldn't it take up space?
- thayne 1y agoIs it 3x as important? Because currently, for a single line of happy path code you often have 3 lines of error handling code. And while handling errors is important, it is also often trivial, just optionally wrapping the error and returning it up to the caller. I agree it is good for that to be explicit, but I don't think it needs to take up more space than the actual function call. In my experience, the important error handling code is either at the lowest layer, where the error initiall occurs, or at the top level, where the error is reported to the user. Mid level code usually just propagates errors upwards.