Golang设计上不会检测/报告死代码,是这样吗?

huangapple go评论87阅读模式
英文:

dead code is not detected/reported in golang, by design?

问题

我可以接受任何函数并在其中间插入panic("don't"),而不是在任何分支或循环内部(使函数的其余部分成为"无效"代码),而Go编译器会愉快地编译和运行,而不会报告这个问题。

有人知道这是设计上的吗?(编译器会大声抱怨未使用的导入,那为什么不抱怨无效代码呢...)他们现在不能回头改变这种行为,因为Go 1已经发布,他们会破坏现有的良好代码。只是想知道这是一个疏忽还是有意为之。如果是疏忽的话,我猜它将等到Go 2(他们可以打破东西的时候)才会解决。

英文:

I can take any function and throw panic("don't") right in the middle of it, not inside any branch or loop (making the remainder of the function "dead" code), and the go compiler will happily compile and run without reporting that as a problem.

Anyone know if this is by design? (The compiler loudly complains about unused imports, so why not dead code...) They can't go back now and change that behavior since Go 1 is released and they'd be breaking existing well-formed code. Just wondering if this is an oversight or something intentional. If an oversight I guess it'll have to wait until Go 2 (when they can break stuff).

答案1

得分: 2

简短回答: 没有人真的在乎。

较长回答:

正如@Volker所指出的,这并没有太大的区别。

我的问题是特指这种行为是否是有意为之。 (这可能是一个不适合在SO上提问的问题,但无论如何。)我想知道这是否是有意为之,还是只是一个疏忽。

Java和其他语言都这样做,所以我想知道是否有一些“不,我们在Go中不这样做,因为...”。看起来并非如此。据我所了解,这只是一个不够重要的问题,不值得花时间去解决。

我也在这里提问过,回复基本上是,是的,这是预期的,很抱歉你不喜欢,它不会改变。已经添加到go vet中,应该足够了。这很好-我同意。

英文:

Short answer: Nobody really gives a rat's ass.

Longer answer:

As @Volker points out, it doesn't make a big difference.

My question was specifically if this behavior is by design. (It's probably a bad question for SO, but oh well.) Was looking to see if this was something that was intentional, or just an oversight.

Java and other languages do it so I was trying to see if there was some "no we don't do that in Go because...". Doesn't seem to be the case. From what I can gather it just wasn't an important enough issue to spend time on putting in.

I asked about this <a href="https://groups.google.com/forum/#!topic/golang-nuts/D-mmT10VBEA">here</a> as well, and the reply was basically that yes, this is expected, sorry you don't like it, it ain't going to change. It's been added to go vet and that should suffice. Which is fine - I agree.

答案2

得分: 0

实际上,这只是暴露了糟糕的编译器设计,因为控制流应该在 panic 处结束。因此,编译器甚至不应该能够在同一控制流路径上翻译 panic 后的代码,甚至不允许有返回语句。如果他们声称这是有意的,那么他们对编译器架构完全失去了控制。这是一个编译器错误,而不是语言的改变。

英文:

Actually, this just exposes bad compiler design, because the control flow should end at the panic. Thus, the compiler should not even be able to translate code after a panic on the same control flow path. Not even a return. If they claim that this is intentional, than they completely lost hold on their compiler architecture. This is a compiler bug, not a language change.

huangapple
  • 本文由 发表于 2013年10月1日 10:22:35
  • 转载请务必保留本文链接:https://go.coder-hub.com/19106954.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定