I was referring to this comment (below) made by a different commentor, which was related to the lock not being released if it panics - and that only matters if the application doesn’t terminate.
> Recovering from panics is a common and IMO perfectly acceptable practice... > For example in a web server where you do not want a panic that occurs while > handling a request to affect other request, especially ones that are in > flight. > On Feb 9, 2019, at 6:48 PM, Michael Jones <michael.jo...@gmail.com> wrote: > > The original question--the one I answered--was about a small block of user > code and asked nothing about http or unexpected panics. > > The spirit of panic/recover, and with defer, includes in its use "local" > panic, a kind of successor to setjump/longjump, that unwinds the stack, calls > defers, and is caught and managed near some local top. As in the blog post I > excerpted: > > https://blog.golang.org/defer-panic-and-recover > <https://blog.golang.org/defer-panic-and-recover> > > On Sat, Feb 9, 2019 at 2:22 PM robert engels <reng...@ix.netcom.com > <mailto:reng...@ix.netcom.com>> wrote: > 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 > > <mailto:i...@golang.org>> wrote: > > > > On Fri, Feb 8, 2019 at 7:48 PM Robert Engels <reng...@ix.netcom.com > > <mailto: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 > > <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 > > <mailto:golang-nuts%2bunsubscr...@googlegroups.com>. > > For more options, visit https://groups.google.com/d/optout > > <https://groups.google.com/d/optout>. > > > > -- > Michael T. Jones > michael.jo...@gmail.com <mailto:michael.jo...@gmail.com> > > -- > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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.
