3 ms·

I find that the differences leap out at me. Even just a `err == nil` instead of `err!= nil` is noticeable. I do have to spend a second reading the action if it

I find that the differences leap out at me. Even just a `err == nil` instead of `err!= nil` is noticeable. I do have to spend a second reading the action if it's not just `return result, fmt.Errorf("failed to do the thing: %w", err)` but that's good, I think. And all of this is way easier than trying to trace up through the stack to the nearest exception handler and work out what it will do with the error edit: also, verbosity doesn't make code harder to understand, imho. If anything the other way around. Packing 5 statements into a single line is massively harder to read than separating those same 5 statements into 20 lines with error handlers.

lmm 3y ago
> And all of this is way easier than trying to trace up through the stack to the nearest exception handler and work out what it will do with the error You still have to do that part though? Like, this function returns err, so the caller returns err, so the caller of that returns err, ... - you've still got to walk up the stack to the point where the error is actually dealt with. > edit: also, verbosity doesn't make code harder to understand, imho. If anything the other way around. Packing 5 statements into a single line is massively harder to read than separating those same 5 statements into 20 lines with error handlers. Very much not my experience. There's a huge understandability hit when a function doesn't fit on a single screen and you have to scroll, so vertical space is really precious.
- marcus_holmes 3y ago
  > you've still got to walk up the stack to the point where the error is actually dealt with. This is why we wrap errors. The error message gives a pretty good indication of what the stack was doing when it went wrong. I had a junior dev work with me on some JS. I was writing it in functional style because it made sense at the time. He was really struggling, so I refactored it to old-school imperative and he understood it and was able to work with it. It might have been an issue with the way he was taught JS, but I think it's more that tightly-packed concise code is actually harder to parse. Not least because you have to understand the whole thing to work out wtf it's doing. Whereas with one-statement-per-line you can scan down to the lines you're interested in and focus on those.

lmm 3y ago

> And all of this is way easier than trying to trace up through the stack to the nearest exception handler and work out what it will do with the error You still have to do that part though? Like, this function returns err, so the caller returns err, so the caller of that returns err, ... - you've still got to walk up the stack to the point where the error is actually dealt with. > edit: also, verbosity doesn't make code harder to understand, imho. If anything the other way around. Packing 5 statements into a single line is massively harder to read than separating those same 5 statements into 20 lines with error handlers. Very much not my experience. There's a huge understandability hit when a function doesn't fit on a single screen and you have to scroll, so vertical space is really precious.

marcus_holmes 3y ago
> you've still got to walk up the stack to the point where the error is actually dealt with. This is why we wrap errors. The error message gives a pretty good indication of what the stack was doing when it went wrong. I had a junior dev work with me on some JS. I was writing it in functional style because it made sense at the time. He was really struggling, so I refactored it to old-school imperative and he understood it and was able to work with it. It might have been an issue with the way he was taught JS, but I think it's more that tightly-packed concise code is actually harder to parse. Not least because you have to understand the whole thing to work out wtf it's doing. Whereas with one-statement-per-line you can scan down to the lines you're interested in and focus on those.