ok, accepting that people use libraries with lurking panics, here's my
tweak of Sam Whitted's answer:
*package main*
*func example() {*
* // robust in face of unruly/panic-possible Operation1*
* lockedOperation1 := func() error {*
* lock1.Lock()*
* defer lock1.Unlock()*
* return performOperation1()*
* }*
* if err := lockedOperation1(); err != nil {*
* return err*
* }*
* performExpensiveOperation2()*
*}*
This is stylistically clear about meaning and motivation, short, and
simple. could be idiomatic.
Of course, if Operation 1 always needs to be locked then put the lock there!
On Sat, Feb 9, 2019 at 5:02 PM robert engels <reng...@ix.netcom.com> wrote:
> 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
>
> On Sat, Feb 9, 2019 at 2:22 PM robert engels <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> 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.
>>
>>
>
> --
>
> *Michael T. jonesmichael.jo...@gmail.com <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.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
--
*Michael T. jonesmichael.jo...@gmail.com <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.
For more options, visit https://groups.google.com/d/optout.
