Re: [go-nuts] Re: Recover considered harmful

2017-04-27 Thread Dave Cheney
The take away for me is; prefer returning an error to to caller wherever possible. Overuse of panic begats overuse of recover and that just leads to more problems [1]. 1. https://github.com/golang/go/issues/13879 -- You received this message because you are subscribed to the Google Groups

Re: [go-nuts] Re: Recover considered harmful

2017-04-27 Thread mhhcbon
> > Most languages, who stick with Exceptions, usually has two kind of > exceptions: > - "exception for regular error", i.e. wrong input, wrong system state, or > for "control flow" > - and "fatal exceptions", > agree to that. Current error management is not satisfying and pushes the

Re: [go-nuts] Re: Recover considered harmful

2017-04-27 Thread Jesper Louis Andersen
On Wed, Apr 26, 2017 at 10:55 AM Peter Herth wrote: > > No, panic certainly does not do that. It prints the stack trace. A proper > logger could add additional information about the program state at the > point of the panic, which is not visible from the stack trace. It

Re: [go-nuts] Re: Recover considered harmful

2017-04-27 Thread roger peppe
On 26 April 2017 at 11:03, Jan Mercl <0xj...@gmail.com> wrote: > On Wed, Apr 26, 2017 at 11:58 AM roger peppe wrote: > >> FWIW I have seen real problems in production where long-running worker > goroutines stopped working. We looked into it and found that certain rare >

Re: [go-nuts] Re: Recover considered harmful

2017-04-26 Thread Sam Whited
On Wed, Apr 26, 2017 at 10:47 AM, Юрий Соколов wrote: > You are not quite right. Sometimes there is scope dependency between Lock > and Unlock, ie Unlock happens not at function exit, but is triggered > asynchronously by some condition. If you can stomach the overhead of

Re: [go-nuts] Re: Recover considered harmful

2017-04-26 Thread Юрий Соколов
s/there is scope dependency/there is no scope dependency/ 2017-04-26 18:47 GMT+03:00 Юрий Соколов : > > Don't Lock without defer Unlock(). (I'm a sinner, just telling what I > learned.) > > You are not quite right. Sometimes there is scope dependency between Lock > and

Re: [go-nuts] Re: Recover considered harmful

2017-04-26 Thread Юрий Соколов
> Don't Lock without defer Unlock(). (I'm a sinner, just telling what I learned.) You are not quite right. Sometimes there is scope dependency between Lock and Unlock, ie Unlock happens not at function exit, but is triggered asynchronously by some condition. More: if you panic cause you already

Re: [go-nuts] Re: Recover considered harmful

2017-04-26 Thread Jan Mercl
On Wed, Apr 26, 2017 at 11:58 AM roger peppe wrote: > FWIW I have seen real problems in production where long-running worker goroutines stopped working. We looked into it and found that certain rare requests were panicking, not releasing a mutex and thus preventing the

Re: [go-nuts] Re: Recover considered harmful

2017-04-26 Thread roger peppe
FWIW I have seen real problems in production where long-running worker goroutines stopped working. We looked into it and found that certain rare requests were panicking, not releasing a mutex and thus preventing the long-running goroutine from acquiring that mutex. This took ages to work out -

Re: [go-nuts] Re: Recover considered harmful

2017-04-26 Thread 'Axel Wagner' via golang-nuts
On Wed, Apr 26, 2017 at 10:55 AM, Peter Herth wrote: > > > On Wed, Apr 26, 2017 at 3:07 AM, Dave Cheney wrote: > >> >> >> On Wednesday, 26 April 2017 10:57:58 UTC+10, Chris G wrote: >>> >>> I think those are all excellent things to do. They do not preclude

Re: [go-nuts] Re: Recover considered harmful

2017-04-26 Thread Peter Herth
On Wed, Apr 26, 2017 at 3:07 AM, Dave Cheney wrote: > > > On Wednesday, 26 April 2017 10:57:58 UTC+10, Chris G wrote: >> >> I think those are all excellent things to do. They do not preclude the >> use of recovering from a panic to assist (emphasis on assist - it is >> certainly

Re: [go-nuts] Re: Recover considered harmful

2017-04-26 Thread Юрий Соколов
`panic/recover` are really bad names for setjmp/longjmp. `throw/catch` are much closer. And C has `assert`. You may set handler for SIGABRT, but then you have to know what are you doing. Usually it is set for backtrace printing only. I mean: usual languages has clean separation between "wrong

Re: [go-nuts] Re: Recover considered harmful

2017-04-25 Thread Kevin Conway
> To try to postpone the exit of a program after a critical error to me implies a much more complex testing and validation process that has identified all the shared state in the program and verified that it is correct in the case that a panic is caught There's an implicit argument here that the

[go-nuts] Re: Recover considered harmful

2017-04-25 Thread Dave Cheney
On Wednesday, 26 April 2017 10:57:58 UTC+10, Chris G wrote: > > I think those are all excellent things to do. They do not preclude the use > of recovering from a panic to assist (emphasis on assist - it is certainly > no silver bullet) in achieving fault tolerance. > > Assuming a web service

[go-nuts] Re: Recover considered harmful

2017-04-25 Thread Chris G
I think those are all excellent things to do. They do not preclude the use of recovering from a panic to assist (emphasis on assist - it is certainly no silver bullet) in achieving fault tolerance. Assuming a web service that needs to be highly available, crashing the entire process due to one

[go-nuts] Re: Recover considered harmful

2017-04-24 Thread Henry
I do think that panic should be avoided whenever possible. I had a third party library that panicked and crashed my application during the production run. If it were to return errors instead, I could have anticipated the problem and handled the situation with a bit more grace. The problem with