Sorry, but I disagree, at least in the context of Go, and the difference
between errors and panics. Imagine any financial service, if the code is
encountering a condition it deems should be impossible, yet is occurring, bad
things will happen. Very old adage, garbage in = garbage out.
> On Feb 8, 2019, at 11:43 PM, Ivan Bertona <i...@ibrt.me> wrote:
>
> 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. 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.
--
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.
