Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: Go 2: improve error handling with “??” keyword for a special case #37243

Closed
infeno opened this issue Feb 15, 2020 · 5 comments
Closed
Labels
error-handling Language & library change proposals that are about error handling. FrozenDueToAge LanguageChange Proposal Proposal-FinalCommentPeriod v2 A language change or incompatible library change
Milestone

Comments

@infeno
Copy link

infeno commented Feb 15, 2020

Would you consider yourself a novice, intermediate, or experienced Go programmer?
Intermediate

What other languages do you have experience with?
PHP, Swift, Javascript

Would this change make Go easier or harder to learn, and why?
Easier to read and less to type.

Has this idea, or one like it, been proposed before?
No, I like to change the meaning of ?? for a special case

Who does this proposal help, and why?
I have seen different ideas for error handling and adding more characters seem requires more time to learn and explaining how it works, why not add 2 symbols?
#21161
#32437
#37165

What is the proposed change?
Propose to add ?? as a shorthand for if err != nil

Is this change backward compatible?
This is a new keyword in additional to the existing ones.

Show example code before and after the change.

Existing approach is explicit and verbose

data, err := getJSONFile(“1.json”)
if err != nil {
	fmt.Println(err)
}

ok := getJSONFile(“1.json”); if !ok {
	fmt.Println(ok)
}

The is valid:
https://github.com/evanw/esbuild/blob/master/src/esbuild/main/main.go#L58

expr, ok := parser.ParseJson(log, source)	
done()
if !ok {
	return false
}

New approach for fast typing

This method is an additional keyword, allowing ?? to be translated into if err != nil behind the scene.

data, err := getJSONFile(“1.json”) ?? {
	fmt.Println(err)
}

err := getJSONFile(“1.json”) ?? {
	fmt.Println(err)
}
  1. Does not need to repeat if err != nil all the time when ?? keyword took <1 second to type.
  2. Less noise, more productivity, will probably have an impact on developers’ pattern.
  3. It purpose is strictly for handling error scenario since ?? is not implemented in Go.
  4. The shortest keyword, in return we get the best readability.

What is the cost of this proposal? (Every language change has a cost).
* What is the compile time cost?
Negligible, as it can be translate behind the scene.

Can you describe a possible implementation?
No

How would the language spec change?
No

Orthogonality: how does this change interact or overlap with existing features?
This change enable developers to type less and improve readability.

Is the goal of this change a performance improvement?
Compiler: no, Developer: yes

Does this affect error handling?
Yes

  • Is this about generics?
    No
@ianlancetaylor ianlancetaylor changed the title Improve error handling with “??” keyword for a special case proposal: Go 2: improve error handling with “??” keyword for a special case Feb 15, 2020
@gopherbot gopherbot added this to the Proposal milestone Feb 15, 2020
@ianlancetaylor ianlancetaylor added error-handling Language & library change proposals that are about error handling. v2 A language change or incompatible library change LanguageChange labels Feb 15, 2020
@ianlancetaylor
Copy link
Contributor

You answer "no" to the question about whether this is about error handling, but it seems to me that this proposal is all about error handling.

I note that there is a separate proposal for ?? at #37165. One nice feature about Go is that with a couple of exceptions it's quite readable for people familiar with languages like C or Java. The C# language has a ?? operator that does null coalescing, and as such is quite different from the suggestion here. I'm not aware of any language that uses ?? as anything like the idea here.

@infeno
Copy link
Author

infeno commented Feb 15, 2020

Yes, my proposal is about error handling, I have misread it.

True, I have also commented in #37165. I understand other language use ?? but this would be a special case for Go, could be thought as a simple magic if it's appropriate.

@ianlancetaylor
Copy link
Contributor

This new syntax is only slightly shorter than the existing syntax. As is noted above, this is quite similar to existing proposals which were declined. Based on emoji voting, there is no support for this change. Therefore, this is a likely decline. Leaving open for four weeks for final comments.

@andreygrehov
Copy link

andreygrehov commented Feb 29, 2020

Isn't it essentially the same as the closed onerr proposal #32848?

@ianlancetaylor
Copy link
Contributor

No change in consensus, so closing.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
error-handling Language & library change proposals that are about error handling. FrozenDueToAge LanguageChange Proposal Proposal-FinalCommentPeriod v2 A language change or incompatible library change
Projects
None yet
Development

No branches or pull requests

4 participants