Agree to that.
>From the original blog post:
The convention in the Go libraries is that even when a package uses panic
internally, its external API still presents explicit error return values.
But yes, agree with the problem in the situation that you describe
On Fri, Feb 8, 2019 at 4:24 PM Ivan Bertona <i...@ibrt.me> wrote:
> What's suboptimal with the first one (or the second one) is that if
> performOperation1() panics the lock will not be released. It may or may not
> be a problem depending on the situation. Your assessment of defer used with
> locks is correct - it works well only if the lock doesn't need to be
> released before the end of the function - but in my experience you can
> always extract a function to achieve that. If you can't, it's usually a
> sign that the code needs some reworking.
>
> On Friday, February 8, 2019 at 7:03:28 PM UTC-5, Michael Jones wrote:
>>
>> I don’t see anything suboptimal about the first one.
>>
>> Defer is a function-scope magic thing.
>>
>> Go designers chose not to have lexical scope magic, so you would either
>> force function scope (prior answer) or be happy with the normal code.
>>
>> On Fri, Feb 8, 2019 at 10:31 AM Burak Serdar <bse...@ieee.org> wrote:
>>
>>> On Fri, Feb 8, 2019 at 11:28 AM vincent163 <hwy14...@gmail.com> wrote:
>>> >
>>> > I am thinking about how to write programs like this:
>>> > lock1.Lock()
>>> > err = performOperation1()
>>> > if err != nil {
>>> > lock1.Unlock()
>>> > return err
>>> > }
>>> > lock1.Unlock()
>>> > performExpensiveOperation2()
>>>
>>> How about this:
>>>
>>> lock1.Lock()
>>> err = performOperation1()
>>> lock1.Unlock()
>>> if err != nil {
>>> return err
>>> }
>>> performExpensiveOperation2()
>>>
>>>
>>> >
>>> >
>>> > The lock1 must be locked while performing operation1, and I need to
>>> use its result to perform operation2. Since operation2 is expensive, I
>>> don't want to hold the lock while performing it, and lock1.Unlock() needs
>>> to be called before calling operation2.
>>> > Go's defer mechanism doesn't seem to handle this case well since the
>>> resource is used only within a block and not throughout the function. Is
>>> there a recommended way to write programs in this case?
>>> > I know I could wrap the lock block in a closure, but that creates a
>>> completely new scope, so I can't return directly or break out of a loop
>>> within the closure, etc.
>>> >
>>> > --
>>> > 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.
>>> > 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...@googlegroups.com.
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>>
>> *Michael T. jonesmichae...@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.
