go - os.Exit 后不应该无法访问代码

Question

去 1.12 窗口

在 os.Exit 之后而不是之前放错了 fmt.Println，
这不应该导致编译器失败或至少警告吗？

package main

import (
    "fmt"
    "os"
)

func main() {
    fmt.Println("Hello, playground")
    os.Exit(0)
    fmt.Println("Good By, playground")
}

Answer 1

os.Exit() 就像任何其他函数一样，编译器不应该知道它会终止应用程序，因此后面的其余代码是无法访问的。 os.Exit()只是一个例子，还有更多，例如 log.Fatal() (调用 os.Exit() )。更不用说您还可以创建一个调用其中之一的函数，编译器应该多远才能检测到所有或大部分？
更进一步，Go 编译器不会检测或标记“真正”无法访问的代码。使用 return 时的以下变化声明甚至对编译器来说是显而易见的:

func main() {
    fmt.Println("Hello, playground")
    return
    fmt.Println("Good By, playground")
}

然而它编译和运行得很好，并且输出(在 Go Playground 上试试):

Hello, playground

所以编译器不会检测到无法访问的代码，而是go vet确实，它也由 Go Playground 运行，因此您可以看到应用程序的输出前缀为:

./prog.go:10:2: unreachable code
Go vet exited.

之前已经提出过，请参阅 cmd/gc: report unreachable code #9501 .罗伯特·格里斯默的回应是:

Generally, Go's philosophy is not to protect the programmer at all costs from his/her mistakes. It's deliberate to not raise an error for unreachable code. It's also not a very common kind of mistake. Besides, it's often useful to introduce early returns for debugging which may cause plenty of unreachable code. It's not clear the benefits outweigh the costs and disadvantages.

Unused variables can lead to subtle find bugs in conjunction with Go's re-declaration mechanism in short variable declarations - hence the error message for unused variables. This is a mechanism that evolved from experience and is a pragmatic solution for a concrete problem.

Unused imports are reported because it helps keeping dependencies under control - an important tool in large-scale systems design and as a side-effect it also keeps compile times fast. Again a very deliberate design decision.

Finally, making dead code an error would be a significant language change which is out of the question at this point.

Use go vet.