ok, accepting that people use libraries with lurking panics, here's my
tweak of Sam Whitted's answer:
*package main*
*func example() {*
* // robust in face of unruly/panic-possible Operation1*
* lockedOperation1 := func() error {*
* lock1.Lock()*
* defer lock1.Unlock()*
* return
I was referring to this comment (below) made by a different commentor, which
was related to the lock not being released if it panics - and that only matters
if the application doesn’t terminate.
> Recovering from panics is a common and IMO perfectly acceptable practice...
> For example in a
The original question--the one I answered--was about a small block of user
code and asked nothing about http or unexpected panics.
The spirit of panic/recover, and with defer, includes in its use "local"
panic, a kind of successor to setjump/longjump, that unwinds the stack,
calls defers, and is
I agree, but in that case the ‘panic’ is as you say recognized (and in this
particular case used to unwind from a potentially very deep call), but is then
still returned as an error.
The previous commentor referred to catching “panics" in a top-level http
request processor and continuing to
On Fri, Feb 8, 2019 at 7:48 PM Robert Engels wrote:
>
> The way Go is designed a panic must terminate the application. Anything else
> is so indeterminate to be unusable.
I think one can reasonably argue that an unrecognized panic should
terminate the application.
But there is nothing wrong
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
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
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 wrote:
> The way
It's not pretty, but if you absolutely must write this code and can't refactor
it, you can always use a closure to scope the defer:
lock1.Lock()
err = func() error {
defer lock1.Unlock()
return performOperation1()
}()
if err != nil {
return err
}
performExpensiveOperation2()
On Fri, Feb
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
On Fri, Feb 8, 2019 at 11:28 AM vincent163 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 =
I am thinking about how to write programs like this:
lock1.Lock()
err = performOperation1()
if err != nil {
lock1.Unlock()
return err
}
lock1.Unlock()
performExpensiveOperation2()
The lock1 must be locked while performing operation1, and I need to use its
result to perform operation2. Since
12 matches
Mail list logo
