I agree, but in that case the ‘panic’ is as you say recognized (and in this particular case used to unwind from a potentially very deep call), but is then still returned as an error.
The previous commentor referred to catching “panics" in a top-level http request processor and continuing to service requests - which is far different in my opinion. > On Feb 9, 2019, at 4:08 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Fri, Feb 8, 2019 at 7:48 PM Robert Engels <reng...@ix.netcom.com> wrote: >> >> The way Go is designed a panic must terminate the application. Anything else >> is so indeterminate to be unusable. > > I think one can reasonably argue that an unrecognized panic should > terminate the application. > > But there is nothing wrong with recovering and continuing from a > recognized panic. For example, the call to recover in > encoding/json.encodeState.marshal is fine > (https://golang.org/src/encoding/json/encode.go#L295). > > Ian > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
