On Sun, 4 Jun 2023 12:36:20 -0700 Ian Lance Taylor <i...@golang.org> wrote:
> On Sun, Jun 4, 2023 at 9:17 AM Shulhan <m.shul...@gmail.com> wrote: > > > > I have been reading several proposals about error handling couple of > > months ago and today a light bulb come upon me, and then I write as > > much as I can think. I am not sure if its good or bad idea or even > > possible to implement. > > > > In this post, I will try as concise as possible. > > The full and up to date proposal is available at > > https://kilabit.info/journal/2023/go2_error_handling/ . > > > > Any feedback are welcome so I can see if this can move forward. > > Thanks. Perhaps I misunderstand, but this seems to provide a > different way of writing an if statement and a goto statement. > Instead of writing > > if err != nil { > goto parseError > } > > I can write > > when err handle parseError > In some sense yes, it is identical to writing and combining if and goto statements. The semantic of `when` different on the condition that they evaluate. The `if` statement only continue if expression evaluate to true, the `when` condition only continue if the expression evaluate to non-zero value. So, the "when" statement provide a connection with the handle label. The goto imply that the statements before it fall-through after it. For example, S0 goto1: S1 goto2: S2 Statement S1 will be executed after S0, statement S2 will be executed after S1. Case in example, the following goto example will loop forever, if true { goto goto2 } goto1: println("goto1") goto2: println("goto2") goto goto1 While handle ":name:" scope only on that handle body. The following properties describes how handle and its label are different with goto and its label, * Each of `HandleStmt` MUST be declared at the bottom of function block. * An `HandleStmt` can call other `HandleStmt` as long as the handle is above the current handle and it is not itself. * Any statements below `HandleCallStmt` MUST not be executed. * Unlike goto, each `HandleStmt` is independent on each other, one `HandleStmt` end on itself, either by calling `return` or `handle`, or by other `HandleStmt` and does not fall-through below it. For example, S0 :handle1: S1 :handle2: S2 Statement S0 stop and never fall-through :handle1:. Statement S1 stop and never fall-through :handle2:. Case in example, the following handle will not end with infinite loop, ... when err handle handle2 :handle1: println("handle1") :handle2: println("handle2") handle handle1 > Any change to error handling is going to affect all Go code > everywhere. If we change anything it needs to be a big improvement. > It's not worth changing all Go code everywhere for a small > improvement. After all, Go does work OK today for most people. Agree with that. The original purpose of this proposal in the Abstract [1] is that its not only can be use for handling error but also for handling other control flow. The goals is not to reduce number of lines but to minimise repetitive error handling. > It's > not clear to me that this proposal is a big enough improvement. > Thanks. I am shooting in the dark here and see if it make sense from other perspective. Thanks for reviewing. -- [1] https://kilabit.info/journal/2023/go2_error_handling/#abstract -- 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/20230617134702.1b136cf0%40inspiro.localdomain.
pgpnP3sjfGS3P.pgp
Description: OpenPGP digital signature
