3 ms·

You have been mislead. Better advice for panicing in Go is to panic in truly exceptional or unrecoverable circumstances. For example, a programmer error (violat

You have been mislead. Better advice for panicing in Go is to panic in truly exceptional or unrecoverable circumstances. For example, a programmer error (violating the terms of a function contract) is a perfectly reasonable justification for panicing across package boundaries. The Go standard library: grep -nrHIF 'panic(' /opt/go/src/pkg/* | wc -l 632 Note that this is somewhat inflated with a lot of `panic("unreachable")` calls. They are a symptom of the standard Go Compiler requiring a `return` on every code path of a function that returns at least one value. A `panic(...)` relaxes this requirement. In this case, a panic arising would indicate a bug in the package. Which is another good reason to panic across package boundaries :-)

frou_dh 14y ago
Alright, that makes more sense to me. Do you know if they intend to fix the need for phoney code paths? It seems odd that a language with nice support for first class functions and closures can't acknowledge when "if ... else ..." has complete flow coverage.
- burntsushi 14y ago
  > Do you know if they intend to fix the need for phoney code paths? It's a purposeful restriction imposed by the Go compiler, but not by the Go language specification. And I think the idea is to encourage explicitness, and force cases like these: if cond { return ... } else { return ... } Into a simpler: if cond { return ... } return ... Reasonable people can disagree over whether this is a Good Thing.