标记OS.Exit后不应出现无法访问的代码 [英] shouldn't unreachable code after os.Exit be flagged

问题描述

转到1.12窗口

将fmt.Println放到os.Exit之后而不是之前， 难道这不应该导致编译器失败或至少是警告吗?

misplaced a fmt.Println after os.Exit instead of before, shouldn't this have gotten a compiler failure or at least warning?

package main

import (
    "fmt"
    "os"
)

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

推荐答案

os.Exit() 就像其他函数一样，编译器不应该知道它会终止应用程序，因此后面的其余代码是无法访问的. os.Exit()只是一个示例，还有更多示例，例如 log.Fatal() (该调用os.Exit()).更不用说您还可以创建一个调用其中之一的函数，编译器应该走多远才能检测到全部或大部分这些东西?

os.Exit() is just like any other function, the compiler should not know it terminates the app and so the rest of the code that follows is unreachable. os.Exit() is just one example and there are more, e.g.log.Fatal() (which calls os.Exit()). Not to mention you can also create a function which calls one of these, how far should the compiler go to detect all or most of these?

更进一步，Go编译器不检测也不标记真正的".无法访问的代码.使用return语句时的以下变化甚至对编译器来说很明显:

Going further, the Go compiler does not detect nor marks "truly" unreachable code. The following variation when using a return statement could even be obvious to the compiler:

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

但是它可以编译并正常运行，并可以输出(在进入游乐场上尝试):

Yet it compiles and runs just fine, and outputs (try it on the Go Playground):

Hello, playground

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

So the compiler does not detect unreachable code, but go vet does, which is also run by the Go Playground, and so you can see the app's output prefixed by:

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

此问题之前曾提出过，请参见 cmd/gc:报告无法访问的代码#9501 .罗伯特·格里瑟默(Robert Grisemer)的回应是:

This has been brought up before, see cmd/gc: report unreachable code #9501. Robert Grisemer's response was:

通常，Go的理念是不全力保护程序员免受错误的侵害.故意不要为无法访问的代码引发错误.这也不是很常见的错误.此外，引入早期返回调试信息通常很有用，这可能会导致大量无法访问的代码.尚不清楚收益大于成本和不利.

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.

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

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.

请使用兽医.

这篇关于标记OS.Exit后不应出现无法访问的代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！