Hi Justin, thanks for reviewing, sorry for late response. On Sun, 4 Jun 2023 17:28:29 -0700 (PDT) Justin Israel <justinisr...@gmail.com> wrote:
>
> I don't really understand the comparison between this proposal and
> the referenced previous one.
If we see one of the first code in the previous proposal design,
...
handle err {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
r := check os.Open(src)
...
There is no explicit link between the "check" keyword and how it will
trigger "handle err" later.
It is also break the contract between the signature of "os.Open", that
return an error in the second parameter and the code that call it.
In other words, if someone new to the code, we need to explain to them
that os.Open _actually_ return an error as second return value, and
that is being checked by "check" using handle.
This proposal try to make the link between them clear and
keep the code flow explicit and readable, I think.
> This new proposal effectively makes you have to handle errors for
> every call site, just like we do now, but with the indirect flow of
> jumping to a new section of code. And it requires 2 new keywords and
> new label syntax to achieve it. Could we not replicate this behavior
> the same way with nested local scope functions as the handlers and
> just call them with normal if logic?
>
Some disadvantages of using function to handle error are, first, its
expect the call to the function pass the required parameters and handle
the returned value back by the caller.
Second, the context between the error to be handled and function to be
called can be far away (the error function may be defined in different
file or outside of current package).
When using HandleStmt all required variables that cause the errors and
the error itself is in the same scope, there is no flow break between
the cause and handler, except the jump that you mentioned above.
--
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/20230617135930.4cc3d0b6%40inspiro.localdomain.
pgp6MJ7zT69oF.pgp
Description: OpenPGP digital signature
