Reputation: 11397
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).
Upvotes: 4
Views: 2794
Reputation: 33
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.
Upvotes: 0
Reputation: 11397
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 here 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.
Upvotes: 2