操作系统后不应该无法访问代码。标记退出

Question

go 1.12 窗口

放错了FMT。Println after os.退出而不是之前， 这不应该得到编译器失败或至少警告吗？

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：报告无法访问的代码 #9501。Robert Grisemer的回应是：

一般来说，Go 的哲学不是不惜一切代价保护程序员免受他/她的错误的影响。故意不为无法访问的代码引发错误。这也不是一种很常见的错误。此外，引入早期返回调试通常很有用，这可能会导致大量无法访问的代码。目前尚不清楚利大于弊。

未使用的变量可能会导致在短变量声明中与 Go 的重新声明机制一起出现微妙的查找错误 - 因此未使用变量会出现错误消息。这是一种从经验中演变而来的机制，是解决具体问题的务实办法。

报告未使用的导入是因为它有助于控制依赖项 - 这是大规模系统设计中的重要工具，并且作为副作用，它还保持了编译时间的快速。又是一个非常深思熟虑的设计决定。

最后，使死代码成为错误将是一个重要的语言更改，这在这一点上是不可能的。

使用去兽医。