Very nice snippetI
Like how you wrap in a clousure the critical section using a lock that
comes from the enviorement.
I don't know if it is idiomatic but it could be!, and btw this really helps
the original "questioner" (using er to honour golang "er" sufix)
Thanks for sharing
El domingo, 10 de
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 performOperation1
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 web
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 c
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 ser
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 wit
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 prob
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
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 G
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 wrote:
>
> Agree to that.
>
> From the original blog post:
>
> The convention in the Go libraries is that even when a package uses pa
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 8,
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
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
releas
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 wrote:
> On Fri
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 = perform
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 o
16 matches
Mail list logo
