go: proposal: check - a minimal error handling improvement for readability

I like the implicit non nil checks with the explicit return of the error from your proposal. I understand why you write the declaration of err but I think this could still be part of the normal variable declaration. The ´check´ could be tied to the variable instead of the function call, indicating that the variable will be non nil checked

The following would be a ‘smaller’ language change, could work with other types than error and would still fullfill most of the goals of this proposal:

func readFile(name string) ([]byte, error) {
    f, check err := Open(name) {
        return nil, err
    }
    defer f.Close()

    contents, check err := readContents(f) {
        return nil, fmt.Errorf("error reading %s: %w", name, err)
    }

    // the validate call is in the middle of a lot of boilerplate, impacting readability
    // here a new err variable shadows the existing one, a potential for confusion/bugs
    check err := validate(contents) { 
        return nil, err
    }

    return contents, nil
}

Since it is impossible to confuse assignments and comparissons in declarations because you cannot compare a not declared variable. This could actually use the existing if keyword instead of check:

func readFile(name string) ([]byte, error) {
    f, if err := Open(name) {
        return nil, err
    }
    defer f.Close()

    contents, if err := readContents(f) {
        return nil, fmt.Errorf("error reading %s: %w", name, err)
    }

    // the validate call is in the middle of a lot of boilerplate, impacting readability
    // here a new err variable shadows the existing one, a potential for confusion/bugs
    if err := validate(contents) { 
        return nil, err
    }

    return contents, nil
}

It seems like the closest current form to what’s being proposed here is the if statement with a “simple statement” appearing before the predicate, like this part of the motivating example:

	if err := validate(contents); err != nil { 
		return nil, err
	}

The form above already confines the err symbol to the body of the if statement, solving your problem statement 2, and the happy/error path interleaving seems the same as your proposal and so I think both this and your proposal are equal under problem statement 3.

I believe the following is the closest equivalent to the above example under your proposal:

	check validate(contents); err {
		return nil, err
	}

This has:

• Replaced if with check.
• Made the err != nil predicate implied rather than explicit.
• Moved the err variable declaration to after the semicolon, replacing the now-implied predicate.

I would agree that there’s less boilerplate in this form than in the if statement form I included above, and therefore it might represent an improvement to problem statement 1: “verbose”.

A typical reason I’ve heard for not using this if err := ...; err != nil { pattern is that to some readers it “hides” the most important information – the function call – behind some other content. It therefore makes it harder to skim the code. I don’t personally have a strong opinion on that, but it does seem like your proposal reduces the amount of content appearing before the function call, reducing it to just the single keyword check. Perhaps with some time to grow accustomed to it Go readers would find that comfortable to skim.

Based just on the above I don’t feel super convinced this is enough of an improvement to justify the exception in the language. I do agree that it is an improvement, but the improvement feels marginal by this criteria.

---

I think you’ve buried the lede a bit in your proposal because what you suggested does introduce something new that’s materially different from the typical if statement but that I didn’t quite lock onto until a second read: it allows declaring new symbols both in the parent scope (the non-error results) and the child scope (the error result) without requiring a separate declaration statement.

I missed it on my first read because the example you chose for the if block was a function that only returns an error, but let’s consider how my if statement would look for your readContents example.

I see two main ways to lay it out. The first would be to indent both the happy path and the error path so that neither appears in the parent scope:

	if contents, err := readContents(f); err == nil {
		// happy path using "contents"
	} else {
		// error path using "err"
	}

I’m sure most would agree that the above is not idiomatic because we typically expect the happy path to be unindented and only the error branch to be indented.

The other way is to hoist one of the variable declarations out of the if:

	var contents []byte
	if contents, err := readContents(f); err != nil {
		// error path using "err"
	}
	// happy path using "contents"

Of course in practice I’d probably write this just like you wrote it in your original example, with the whole call on the line above the if statement and only if err != nil, but I’ve written it this way because it’s the closest I can get to meeting your criteria 2 (err only being declared in the nested scope) with today’s Go. And of course this is only true if you exclusively write it this way, so that no other earlier statements have already declared an err in the parent scope.

One thing I quite like about your proposal then is that it quite neatly handles this “scope splitting” goal, allowing contents and err to both be declared by the same statement but for err to belong only to the child scope:

	contents := check readContents(f); err {
		// error path using "err"
	}
	// happy path using "contents"

I will say that the exact details of the syntax feel a little awkward to me – it isn’t super clear that the err after the semicolon is effectively a variable declaration – but I think the broad idea is interesting and does add something new to the language, albeit perhaps a relatively small thing. It is at least cosmetically similar to the switch statement form that has a simple statement embedded in it, like switch foo := bar(); foo {, but even in this case that terminal foo is an expression rather than a declaration.

But I think it’s probably more important to discuss what the desirable properties of a solution are than to debate the exact details of syntax, so I won’t quibble too much about the syntax details. If it seems (to others in this discussion) like this “scope splitting” behavior is desirable then I’m sure there are various other possible syntax shapes to consider that would make different tradeoffs of terseness vs. similarity to existing language constructs.

I’m also not super convinced that this new capability is sufficiently useful to justify the extra language complexity, but I could imagine myself getting used to this pattern and enjoying it if it were in the language.

Why don’t make it as a directive ? like //go:check {NilType Return Name}, this can accept a wide range and not just errors but any types that can have nil value. in code

func readFile(name string) (content []byte, err error) {
	//go:check err 
        f, err := Open(name)
	defer f.Close()

	content, err = func(fs *File) (f, []byte, err error) {
	        
	        //go:check f, err
                f, err = fs.Body()          

        }
        //go:check err
	err = validate(contents)
	return 
}

Since func() (err error) “err” can either return the default or the value assigned to before //go:check

Regarding how this would be integrated into the language grammar - there are of course several possible ways to do it depending on how many places you would want to allow checks to be used. Given that one of the criticisms of proposal https://github.com/golang/go/issues/32437 was that try could be used in any expression and thus lead to very complicated code my suggestion would be the following:

Statement =
	Declaration | LabeledStmt | SimpleStmt |
	GoStmt | ReturnStmt | BreakStmt | ContinueStmt | GotoStmt |
	FallthroughStmt | Block | IfStmt | SwitchStmt | SelectStmt | ForStmt |
	DeferStmt | CheckStmt .

CheckStmt = [IdentifierList ":="] "check" Expression [";" identifier Block] .

“;” would be replaced with “else” if that is considered preferable.

From a grammar point of view it would be cleaner to put the check keyword first in the statement to be more similar to “if”, “for” etc… in that case the grammar would be:

CheckStmt = "check" [IdentifierList ":="] Expression [";" identifier Block] .

This is not as clean from a readability standpoint IMO, but it would on the other hand make check always be first on the line so that it becomes as visible as return.

Thanks, appreciate it!

Again the main argument is that this:

func readFile(name string) ([]byte, error) {
	f := check Open(name)
	defer f.Close()

	contents := check readContents(f); err {
		return nil, fmt.Errorf("error reading %s: %w", name, err)
	}

	check validate(contents)

	return contents, nil
}

is more readable than this:

func readFile(name string) ([]byte, error) {
	f, err := Open(name)
	if err != nil {
		return nil, err
	}
	defer f.Close()

	contents, err := readContents(f)
	if err != nil {
		return nil, fmt.Errorf("error reading %s: %w", name, err)
	}

	if err := validate(contents); err != nil { 
		return nil, err
	}

	return contents, nil
}

while also always keeping err variables local to the error handling scope, thanks.