Very nice snippetI
Like how you wrap in a clousure the critical section using a lock that
comes from the enviorement.
I don't know if it is idiomatic but it could be!, and btw this really helps
the original "questioner" (using er to honour golang "er" sufix)
Thanks for sharing
El domingo, 10 de febrero de 2019, 3:28:45 (UTC-3), Michael Jones escribió:
>
> ok, accepting that people use libraries with lurking panics, here's my
> tweak of Sam Whitted's answer:
>
> *package main*
>
> *func example() {*
>
> * var lock1 sync.Lock <-- Guess here will fit !*
> * // 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 <ren...@ix.netcom.com
> <javascript:>> 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 <michae...@gmail.com
>> <javascript:>> 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 <ren...@ix.netcom.com
>> <javascript:>> 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 <ia...@golang.org
>>> <javascript:>> wrote:
>>> >
>>> > On Fri, Feb 8, 2019 at 7:48 PM Robert Engels <ren...@ix.netcom.com
>>> <javascript:>> 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...@googlegroups.com <javascript:>.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>
>> --
>>
>> *Michael T. jonesmichae...@gmail.com <javascript:>*
>>
>> --
>> 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...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>
> --
>
> *Michael T. jonesmichae...@gmail.com <javascript:>*
>
--
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.
