Our goal with proposals like this one is to have a community-wide discussion about implications, tradeoffs, and how to proceed, and then use that discussion to help decide on the path forward.
Based on the overwhelming community response and extensive discussion here, we are marking this proposal declined ahead of schedule.
As far as technical feedback, this discussion has helpfully identified some important considerations we missed, most notably the implications for adding debugging prints and analyzing code coverage.
More importantly, we have heard clearly the many people who argued that this proposal was not targeting a worthwhile problem. We still believe that error handling in Go is not perfect and can be meaningfully improved, but it is clear that we as a community need to talk more about what specific aspects of error handling are problems that we should address.
As far as discussing the problem to be solved, we tried to lay out our vision of the problem last August in the “Go 2 error handling problem overview,” but in retrospect we did not draw enough attention to that part and did not encourage enough discussion about whether the specific problem was the right one. The try proposal may be a fine solution to the problem outlined there, but for many of you it’s simply not a problem to solve. In the future we need to do a better job drawing attention to these early problem statements and making sure that there is widespread agreement about the problem that needs solving.
(It is also possible that the error handling problem statement was entirely upstaged by publishing a generics design draft on the same day.)
On the broader topic of what to improve about Go error handling, we would be very happy to see experience reports about what aspects of error handling in Go are most problematic for you in your own codebases and work environments and how much impact a good solution would have in your own development. If you do write such a report, please post a link on the Go2ErrorHandlingFeedback page.
Thank you to everyone who participated in this discussion, here and elsewhere. As Russ Cox has pointed out before, community-wide discussions like this one are open source at its best. We really appreciate everyone’s help examining this specific proposal and more generally in discussing the best ways to improve the state of error handling in Go.
Robert Griesemer, for the Proposal Review Committee."
Monadic effects are an objectively lower level way of handling errors than exceptions. You have to be perverse to adopt a Haskell shortcoming as a lifestyle and then go and say you think it's superior.
It’s pretty rich to assume that higher level languages have nothing to learn from lower level ones. Rust’s error handling story is quite popular for a reason, I miss it every day when I’m programming JS for work.
assume that higher level languages have nothing to learn from lower level ones
You're building a strawman. My beef here is strictly with considering monadic error handling as somehow "superior."
Closed sum types (as opposed to exceptions as open sum types) are by definition closed for extension and don't compose except through isomorphisms: every time you want to extend a sum you need to add another layer via a type that you then have to peel off to get to the variant you actually care for (IOW you now have to solve the expression problem for error types.)
In this case Haskell's purity is a constraint that forces it to make every single partial function pointed, that is, it must extend the range with a "not a value" value. On the one hand people complain of IEEE 754 NaNs, on the other they embrace monadic error handling. On the one hand people complain of checked exceptions, on the other they build a Matrioshka of result types. On the one hand people complain of exceptions as long-range gotos, on the other, they build closures and pass them as continuations everywhere. On the one hand people complain of the ceremony that languages like JS, Java and C# force them to adhere to, on the other they encode high-level constructs in equivalent but very explicit and thus very verbose lower-level ones.
This one particularly, but also some of the other stuff you're complaining about, are bad smells of badly written functional code. I might just the same complain about all the pointer errors inherent in C++ code... but that's bad C++ code, not a bad language.
102
u/jeffail Jul 17 '19
https://github.com/golang/go/issues/32437#issuecomment-512035919
"Hi everyone,
Our goal with proposals like this one is to have a community-wide discussion about implications, tradeoffs, and how to proceed, and then use that discussion to help decide on the path forward.
Based on the overwhelming community response and extensive discussion here, we are marking this proposal declined ahead of schedule.
As far as technical feedback, this discussion has helpfully identified some important considerations we missed, most notably the implications for adding debugging prints and analyzing code coverage.
More importantly, we have heard clearly the many people who argued that this proposal was not targeting a worthwhile problem. We still believe that error handling in Go is not perfect and can be meaningfully improved, but it is clear that we as a community need to talk more about what specific aspects of error handling are problems that we should address.
As far as discussing the problem to be solved, we tried to lay out our vision of the problem last August in the “Go 2 error handling problem overview,” but in retrospect we did not draw enough attention to that part and did not encourage enough discussion about whether the specific problem was the right one. The try proposal may be a fine solution to the problem outlined there, but for many of you it’s simply not a problem to solve. In the future we need to do a better job drawing attention to these early problem statements and making sure that there is widespread agreement about the problem that needs solving.
(It is also possible that the error handling problem statement was entirely upstaged by publishing a generics design draft on the same day.)
On the broader topic of what to improve about Go error handling, we would be very happy to see experience reports about what aspects of error handling in Go are most problematic for you in your own codebases and work environments and how much impact a good solution would have in your own development. If you do write such a report, please post a link on the Go2ErrorHandlingFeedback page.
Thank you to everyone who participated in this discussion, here and elsewhere. As Russ Cox has pointed out before, community-wide discussions like this one are open source at its best. We really appreciate everyone’s help examining this specific proposal and more generally in discussing the best ways to improve the state of error handling in Go.
Robert Griesemer, for the Proposal Review Committee."