3 ms·
Only seems useful when you have a function and want every error handled the exact same way, and don't have any requirement to add context the way https://github
by spyspy 8y ago
Only seems useful when you have a function and want every error handled the exact same way, and don't have any requirement to add context the way https://github.com/pkg/errors https://github.com/pkg/errors does.
- ianlancetaylor 8y agoRead the design draft (https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md https://go.googlesource.com/proposal/+/master/design/go2draf...). The issues you raise are addressed.
- spyspy 8y agoNot quite. You'd need to write new `handle err { ... }` blocks for every new context, like how they have one in the for loop. In effect you're just moving the handling of the error away from the place it occurred, which is not optimal. As someone who writes Go every day I don't see this strategy effectively cutting down on boilerplate core or adding clarity.
- tracker1 8y agoWhile this is true, more often than not, in lower-level functions you want errors to bubble up. For example, in most Node.js code, the first line in each callback raises the error to the callback, or likewise throws up in a promise/async chain. Beyond this, there's no reason you can't add additional context and/or wrap the original error before returning your own error. With this additional syntax and the addition of generics, I'm far more likely to take up go. Up to this point, I'd only toyed with it a little, because it just felt so cumbersome to actually get stuff done compared to node. Beyond that, dealing with web-ui, if I'm going to take on a cognitive disconnect for a back-end, I want as little friction as possible.
- spyspy 8y agoMy point is that using this to wrap context around errors is even more verbose than what's available/common today, since you either settle for one wrap for the whole function or you have to define multiple `handle` blocks.
- tracker1 8y agoDoes the "old" way no longer work?
- dvlsg 8y agoI'm in the same boat as you. Error handling and code generation (to support the lack of generics) in go always left a poor impression on me. I ended up going back to node for work, f# or typescript for personal projects. These two changes alone are enough to get me to pick go back up.
- deleted 8y ago[deleted]