Btw, before someone gets the wrong impression. You might trap the panic in a
web container, rather than terminating the process, but every request should
just auto respond with a 500 error. You might need the server live to perform
critical error analysis, but even then the best solution is probably to core
dump, and auto start a backup process that responds with a 500 error. Still in
a cloud app with multiple instances you could have the same problem in multiple
installs just waiting to occur there. Most likely you need to perform a mass
rollback or update.
I didn’t mean to suggest that it was a trivial problem with a trivial solution.
> On Feb 9, 2019, at 12:48 AM, Robert Engels <reng...@ix.netcom.com> wrote:
>
> 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.
--
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.
