ANN: The universal "check" built-in proposal.

[Wojciech S. Czarnecki]

The `func check(Condition bool) {}` applies to the block that follows.
Within this block, every statement that on its left-hand side has any
variable that is present in the "Condition" expression is supplemented
with an implicit check of `if Condition { goto catch }` form.

The 'catch:' label can be given explicit, or be assumed implicit at
last statement of the block.

// Condition is not restricted to `err != nil`.
// Below snippet will `break` if x was < 4 after any of trX calls:

check(x < 4)
{
x, y = trA(x, z)
y, z = trB(x, y) // no x on lhs, no check
x, y = trC(y, z)
break
}


// `check` helps the most where many repetitive checks
// are to be performed in close proximity.

check(err != nil)
{
ucred, err := getUserCredentials(user)
remote, err := connectToApi(remoteUri)
err, session, utok := remote.Auth(user, ucred)
udata, err := session.getCalendar(utok)

catch: // sad path, err != nil
ucred.Clear() // cleanup passwords
remote.Close() // do not leak sockets
return nil, 0, // dress before leaving
fmt.Errorf("Can not get user's Calendar because of: %v", err)
}
// happy path


The proposal is at https://github.com/golang/go/issues/32968

Please leave a comment for your possible thumb-down, as
I would like to know about flaws I do not see as the author.

Thank you,

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

[Robert Engels]

This will never work because of dependent resource allocation. And you wouldn’t be able to check resources against nil if they are structs, so you have no way to properly cleanup up. If would quickly degenerate back to if err != nil.

As in

check(err!=nil){
token, err = getToken()
reader,err = getReader(token)
db,err = get DB(reader)

catch:
How do you know know which resources need to be closed/cleaned-up

> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20190708141334.0de08a9f%40zuzia.
> For more options, visit https://groups.google.com/d/optout.

[Wojciech S. Czarnecki]

On Mon, 8 Jul 2019 07:37:20 -0500
Robert Engels <ren...@ix.netcom.com> wrote:

> This will never work because of dependent resource allocation.
> And you wouldn’t be able to check resources against nil if they are structs,
> so you have no way to properly cleanup up.
> If would quickly degenerate back to if err != nil.

If the functions called in the block follow bad practices -
yes, then the `check` will be harder[1] to use for them.

> As in
>
> check(err!=nil){
> token, err = getToken()
> reader,err = getReader(token)
> db,err = get DB(reader)
>
> catch:

> How do you know know which resources need to be closed/cleaned-up

Because I wrote the getToken and getReader and getDB to return zero
object on err and gave their .Clean() / .Close() methods ability to be invoked
multiple times ? :)

[1] // make bad implementations usable with check:

token := &tokenType{} // assume a pointer out of your "against nil"
reader := new(dummy.Reader)
db := new(mock.DB)

Anyway, your concerns are sound and need (documentation side) attention. Thank you.

[Robert Engels]

Much of the stdlib works in the manner I describe. Yes Go allows invocations on nil interface references, but most implementations will panic.

Multiple Close is almost never a good thing, and most implementations guard against it.

So in the case where the gerReader() succeeds and getDB() fails, how do you clean-up (without a bunch of if clauses, so no better then if err != nil). And what about the cases when the cleanup code returns errors?