I am not sure the ‘unexpected flow control’ concern is of the same importance as when this statement was first written, given paradigms like ‘reactive programming’ (I don’t like it, but it seems most others are not bothered by it).
I am curious more though in the belief that exceptions are unexpected flow control. At least with caught exceptions, this is not the case IMO. You know the exact point at which the exceptions can occur - this is part of the beauty of exceptions in that the code is self documenting to a higher degree and can be subject to automated analysis far more easily (https://arxiv.org/pdf/1708.00817.pdf) In principle, every error in Go should be handled, but the compiler does not enforce this. I also think that try-with-resource solves many of the life-cycle concerns very elegantly (whether you like Java or not, a lot can be learned from the evolution the language). Still caught exceptions cause problems with functional methods (and so does error return), although I’m not a big fan of functional either (for lack of readability). Personally, and I’ve stated it before, but I’ll go on record again, I wouldn’t change Go’s error handling at this point. I don’t think the sweet spot for Go applications requires it, and the difference in mixed code-bases would make things worse not better (e.g. exception based code calling error return based code). But if I were to expand the scope, I would make breaking changes in Go2 (so no mixing of methodology) for both error handling, and generics, and probably a few other things, without regards to backwards compatibility. Go is definitely a better C, but C is a systems language, not a large scale application language. There’s a possibility that Go could be both a great systems language and a great applications language, but I’m doubtful as the concerns are too distinct. > On Jun 30, 2019, at 12:05 AM, Ian Lance Taylor <i...@golang.org> wrote: > > On Sat, Jun 29, 2019 at 12:45 PM Robert Engels <reng...@ix.netcom.com> wrote: >> >> If you don’t understand the history you are doomed to repeat it. The ‘try’ >> proposal is barely better than the current situation. There is as a reason >> exception handling with try catch was designed along with OO. It simplifies >> error handling immensely. “Try” as you might, you might think you are >> improving on it, but you’re not. >> >> Go should implement caught exceptions and be done with it. Stop trying to be >> cute. Take what works elsewhere and stop thinking you’re always the smartest >> person in the room. > > I think that https://golang.org/doc/faq#exceptions is still true. > > One of the commonly mentioned objections to the "try" proposal is that > the try function causes a change in flow of control without clearly > signaling that. In a language where exceptions are thrown to handle > errors, unexpected flow of control is routine. Go does support > exceptions in the form of the panic and recover functions, but they > are stylistically discouraged, so few people use them for error > handling. Experience has shown that unexpected flow of control from > exceptions makes it harder to write correct programs. That is even > more true in a language Go which allocates objects on the stack but > does not have destructors. > > Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/10DCB915-FB30-4F9A-9AFA-E36759269F94%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
