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/CAOyqgcWPXKi4braJ8hX2-R_mS9sS-QQm7qBpaqD%2B_Dhq1CYDMA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
