Shorter error handling

[sanotto]

Go Programming Experience

Intermediate

Other Languages Experience

RPG, Java, C, Rexx ...

Related Idea

• Has this idea, or one like it, been proposed before?
• Does this affect error handling?
• Is this about generics?
• Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit

Has this idea, or one like it, been proposed before?

Really don't know

Does this affect error handling?

Not in the internals

Is this about generics?

No

Proposal

This kind of code pattern emerges once and again in programs ...

value, err := aFunction(parm1,parm2)
if err != null {
panic(err)
}

Or

value, err := aFunction(parm1,parm2)
if err != null {
return nil,err
}

They are usual at evaluanting precondition at the enter of a functión and you have usually two outcomes,
panic or return error with nil values...

Te proposal is to add a couple of "dummy identifiers"

_# (underscore bang)
_<(undercore back)

The idea is instead using this:

value, err := aFunction(parm1,parm2)
if err != null {
panic(err)
}

use

value, _# := aFunction(parm1,parm2)

Instead of using this :

value, err := aFunction(parm1,parm2)

if err != null {
return nil,err
}

Use this :

value, _< := aFunction(parm1,parm2)

It's cosmetic , sintax sugar, but can save a lot of lines of code and thus improve programmers efficiency and improving
even more the fast compilation times.
And it aid code clarity too, less visual clutter.

Compare ...

func callApi(url string, url ssn) boolean {
_# := validateURLFormat(url) //Bad URL ...Bang!
json , _< := getJson(url,ssn) //Couldn't resolve? Exit
ssndata Sssndata = json.Unmarshal(json)
return ssndata.name
}

With

func callApi(url string, url ssn) string {
error := validateURLFormat(url) //Bad URL ...Bang!
if (error != nil) {
panic(error)
}
json String
json , error := getJson(url,ssn) //Couldn't resolve? Exit
if error != null {
return nil, err
}
ssndata Sssndata = json.Unmarshal(json)
return ssndata.name
}
6 Lines vs 13 Lines, half the code, and provided these constructions are pervasive it can reduce codebase size a lot

Language Spec Changes

Nothing internal, if go had a macro replacer it could be done with that

Informal Change

It it just sintatic sugar to avoid writting error checking ifs once and again, in the back, the compiler just insert the code for the if

Is this change backward compatible?

Yes, completely

Orthogonality: How does this change interact or overlap with existing features?

it builds on the blank identifier, extending its reach

Would this change make Go easier or harder to learn, and why?

Easier, because it will make error checking less verbose

Cost Description

I think it's almost free if using a simple preprocessor, then again it could require a change in the tokenizer and parser, that will be more costly, but i think not so much, if the proposed token _# and _< proves hard to implement (they should'nt be if the parser is a lookahead parser) then other symbols could be explored. But I think _# and _< describes panic and return on error quite well in go idiom

Changes to Go ToolChain

just the compiler

Performance Costs

It could help compilation time by reducing code base size, run time cost is just the same

Prototype

Two possible implementations as a pre processor that changes _# and _< in ther if equivalents ...or better changing the lexer and the parser

[gabyhelp]

Related Issues

• Proposal: add token to syntax to reduce error boilerplate #25273 (closed)
• proposal: Go2: error handling shortening #62378 (closed)
• proposal: Go2: error handling with #err suffix #67251 (closed)
• proposal: Go 2: syntactic sugar for error handling (sharp guard) #57052 (closed)
• proposal: Go 2: return error on assignment to _ #65345 (closed)
• proposal: Go 2: reducing "if err != nil" by implicit form of it #41908 (closed)
• proposal: Go 2: allow to mark assigments of errors to return immediately when non-nil or to call a handler function #42318 (closed)
• proposal: Go 2: new syntax for abbreviation of `if err != nil { return ..., err }` #51146 (closed)
• proposal: handle error in minimal way #57552 (closed)
• proposal: Go 2: provide symbol (e.g. #) to abort/panic on non-zero return value #22122 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

This looks like #25273 with a slightly different syntax.

[seankhliao]

Duplicate of #25273

[seankhliao]

see also related proposals like #22122 #35644