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 Fri, Feb 8, 2019 at 10:47 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.
>
> 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. 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.
>
>
--
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.
