4 ms·

I don't think you'll be convinced until you have worked on a Go project of your own. Even then it might take a little while to fully see the point. Go's error

• frou_dh 14y ago
  Do you know whether any calls to the standard library panic over the package boundary? Edit - Things like regexp.MustCompile aside.
  • 4ad 14y ago
    No panics over package boundaries. Breaking this is almost sacrilegious in Go.
    • frou_dh 14y ago
      Yet the standard library does just that? Only on package regexp or elsewhere too? I'm not trying to say I know better than the designers, just that the waters are muddied by supposed rules being broken off the bat.
      • 4ad 14y ago
        Regexp.MustCompile is for initialisation of global variables that is done before main starts. You need a different function than regexp.Compile because you can't process the error at this stage or level. The panic is for exiting the program, since you can't do anything else. It isn't destined to be recovered from.
        • frou_dh 14y ago
          I understand why that's useful. Now, is it safe to say that nothing else in the standard library intentionally surfaces a panic? I'm not trying to troll: I genuinely want to establish this!
          • burntsushi 14y ago
            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.
          • 4ad 14y ago
            Panics serve two purposes: to bring down the program in case of an invariant violation, and to reset a state machine, like setjmp/longjmp in C. See the template package to see what I mean by the latter. The former should not be recovered from. The latter should not cross package boundaries. If they are, it's a bug because only the package author should reset that state machine. Packages should be imune to malicious input. There should be no invariant violations if you supply unexpected input. If you get a panic from a package, it means there's a buga and you shouldn't try to recover from it.
    • burntsushi 14y ago
      This really isn't true. A better characterization is "only panic in exceptional or unrecoverable circumstances." A perfect example of this is programmer error (i.e., violating a function's contract). It's perfectly reasonable to panic over package boundaries in this case.