英文:
Why does Goland color `err` differently?
问题
绿色的 err 表示它是一个新声明的变量。在 Go 语言中，使用 := 运算符可以同时声明并初始化一个新的变量。在你将 if err = ... 改为 if err := ... 后，err 变量被重新声明并初始化，因此它的颜色发生了变化。
英文:
I have this code in Go:
func Provision(env string) error {
primaryPath, err := FindPrimaryRegionForEnv(env)
if err != nil {
return err
}
region := extractRegionFromEnvPath(env, primaryPath)
if err = ProvisionTableInDynamoDB(env, region); err != nil {
return err
}
return nil
}
Which Goland colors like this:
When I change if err = ... to if err := ... then the color of err changes:
What does the greenish err mean?
答案1
得分: 1
这归结于在几乎所有类型安全的语言中，阴影变量的工作方式。在这种情况下，绿色的 err 表示重新声明变量而不是更改其值。
Goland之所以强调这一点，是因为在重新声明的范围内，可能会得到与阴影声明相矛盾的值/类型。
在这个例子中，你有两种不同的行为，err 在 main 块中将是一个 boolean 类型。除非它在 if 条件的范围内，它将被赋予 error 类型。
当你开始在错误场景之外使用阴影变量时，这主要会受到影响，因为你可能会将一个不正确的指针传递给导致意外错误的函数。Go 编译器很难跟踪这些阴影变量，并且不总是在构建时捕获它们。
这可能会在你的生产应用程序中留下意外/未知的错误，用户随后将能够利用它们。
这是一篇关于这个问题的文章，可能也会有用。
https://nidhi-ag.medium.com/variable-shadowing-in-golang-f500e8e58931
英文:
It boils down to how shadow variables work in pretty much all type-safe languages. In this case, green err mean that you're redeclaring the variable rather than changing its value.
The reason why Goland bothered to highlight is this is that within the scope of the redeclaration you may get a value/type that contradicts the shadow declaration.
package main
import (
"errors"
"fmt"
"reflect"
)
func boolErrType() bool {
return false
}
func errType() error {
return errors.New("this is an error")
}
func main() {
err := boolErrType()
if !err {
fmt.Printf("Within boolErrType if condition: %s\n", reflect.TypeOf(err).String())
}
if err := errType(); err != nil {
fmt.Printf("Within errType if condition: %s\n", reflect.TypeOf(err).String())
}
fmt.Printf("Within main function: %s\n", reflect.TypeOf(err).String())
}
https://go.dev/play/p/IwDb7iBZYc2
In this example you've two different behaviours, the err will be a boolean type within the main block. Except for when it's in the if condition scope, it will be given an error type.
This is mainly affected when you've started using shadow variables outside of the error scenarios as you could be for example pass an incorrect pointer to a function that causes an unexpected error. Go compiler will have a hard time tracking these shadow variables and won't always catch them at build time.
This could leave unexpected/unknown bugs in your production applications that user's then will be able to exploit.
Here's an article about this that might be useful as well.
https://nidhi-ag.medium.com/variable-shadowing-in-golang-f500e8e58931
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论