14 ms·
I thought the recent error proposal was quite interesting even if it didn't go through: https://github.com/golang/go/issues/71528 https://github.com/golang/go/i
by evanmoran 10mo ago
I thought the recent error proposal was quite interesting even if it didn't go through: https://github.com/golang/go/issues/71528 https://github.com/golang/go/issues/71528
My hope is they will see these repeated pain points and find something that fits the error/result/enum issues people have. (Generics will be harder, I think)
- Rikudou 10mo agoDidn't they say they're not accepting any new proposals for error handling? I kinda got used to it eventually, but I'll never ever consider not having enums a good thing.
- pa7ch 10mo agoI was a big fan of the original check handle proposal: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf... I see the desire to avoid mucking with control flow so much but something about check/handle just seemed so elegant to me in semi-complex error flows. I might be the only one who would have preferred that over accepting generics. I can't remember at this point because there were so many similar proposals but I think there was a further iteration of check/handle that I liked better possibly but i'm obviously not invested anymore.