On Fri, Oct 21, 2022 at 12:30 PM Daniel Lepage <dplep...@google.com> wrote: > > > In that issue there was considerable resistance to having flow of control > > change as part of an expression. No other part of Go works that way: flow > > of control change is always a keyword, or a call to panic which can only > > occur in statement context. > > This is not true - testing.TB.Fatal, log.Fatal, etc. affect control flow, as > do numerous expressions like nil dereferences or zero divisions, and of > course any function call that triggers any of those (and in extreme cases > like running out of memory practically ANY expression could trigger a control > flow change).
I understand what you are saying. Yes, any function can call panic. Yes, Go also has run-time panics such as division by zero. Yes, there is code that explicitly uses panic and recover to simplify error handling (you don't have to refer to external packages, there is code like that in the standard library, such as encoding/gob). However, I think my broader point still holds despite those facts. I also want to be clear: I'm happy to talk about these issues. But there is basically zero chance that the Go language will add a try/handle syntactic construct. It's possible that the language will make changes regarding error handling, if we ever come to any sort of consensus as to what can and should be done. But it's not going to look like try/handle. 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/CAOyqgcUC4Bc17Z-4s10hFHCpKHtHO-KvtCJHgy5u%3DmRHn6xuZQ%40mail.gmail.com.
