Hacker News Reader

Comment by dragonwriter | Hacker News Reader

> However you generally you don't want to catch panics except under rare conditions because panics are intended to be used in "the world is ending" kind of scenarios

Strange, I've always heard the opposite: if you write a function that can panic, you always want to handle it in your code that calls the function (which should be the only code that could) because panics should generally not be exposed across a public interface, including the boundary between the top-level Go code to the outside world.

View on HN

panics are like asserts. They're here to make sure the program is being used correctly. There is no handling of them, if it's not used correctly you crash.

Of course you do not want to use panic in sensitive code. The best example is looking at how panic() is used in crypto/tls (which has a lot of sensitive code! You really don't want a client to be able to crash a server): https://gist.github.com/mimoo/93c33d88222c87fb384b4ca3b04fb5...

That's simply not true. There is no recovering from a failed assert. Go's recover() allows recovering from panics.

Further, it is considered good practice to recover from panics within library API boundaries, and return errors across the API instead. "The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values."[1]

[1] https://blog.golang.org/defer-panic-and-recover

Yes, if you use panics for control flow in your package, you need to recover from them and hide that fact from your API. That is not the same as saying that you should recover from any panics that happen inside your library. Unexpected panics basically always indicate a programmer error.

Can you give me example in the standard library where they recover from a panic? So far I've only seen recovery through error handling. I think the crypto/tls example is pretty telling on the way they're using panic for sensitive code. No recovery there.

It's common in parsers. JSON parsing can panic (IIRC), as does the go template parsing code. Would they still write it that way today? I don't know.

In net/http, if a handler panics you don't want it to bring down your entire application. For more info, see https://golang.org/pkg/net/http/#Handler

The encoding/json package is interesting because it uses both panic() and recover() internally in a way more reminiscent to how exceptions are used in other languages (that is, for control flow).

For example, https://github.com/golang/go/blob/2596a0c075aeddec571cd658f7... panics, and https://github.com/golang/go/blob/2596a0c075aeddec571cd658f7... recovers it.

Both uses are quite uncommon, though.

interesting! Yeah this is definitely changing my idea of how panic should be used.

Reply on news.ycombinator.com