The way Go is designed a panic must terminate the application. Anything else is
so indeterminate to be unusable.
> On Feb 8, 2019, at 8:08 PM, Michael Jones <michael.jo...@gmail.com> wrote:
>
> 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. Jones
>>> michae...@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. Jones
> 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.
--
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.
