--
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Dave Cheney
Sent: 2017 April 27, Thu 16:54
To: golang-nuts
Subject: Re: [go-nuts] Re: Recover considered harmful
The take away for me is; prefer returning an error to to caller wherever
possible. Overuse of
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
"go
>
> 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 community
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 also
> might at least be r
Den måndag 24 april 2017 kl. 11:02:55 UTC+2 skrev Sokolov Yura:
>
> I want to ask:
> - how useful `recover` for you?
>
In one piece of code it was extremely handy. A TLV protocol decoder taking
a bytes buffer as input. The TLVs could be nested so TLVs containing TLVs
etc. Instead of manually bo
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
> requests were panicking, no
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 yet another stack frame a
On Wed, Apr 26, 2017 at 5:47 PM Юрий Соколов wrote:
> > 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
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 Unlock, ie Unlock happens n
> 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 fo
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 long-running goroutine from
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 - mad
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 the
>>> use of recovering from a panic
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 no silver bullet)
The problem with panic is that it hides an alternate execution path. I think it
is better to make things explicit and obvious.
--
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
The practical issue here is how to use Go effectively to handle various
error/exceptional situations. For that you have to first think about and
understand these scenarios and the best way to handle them. But that is not
simple and context dependent! Example: I may start up N threads in parallel
`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 sta
Recover/panic need not be used only in case of a “critical” error. Just as in
the case of setjmp/longjmp, there are other useful patterns. For example, a
user may ask an interpreter to abandon its current computation by typing ^C.
This would be handled by a longjmp/panic() to regain control at
It looks like there is two point of view:
- optimists who never used to build mutable shared state by them self, and
they hope libraries they use also don't use mutable shared state,
- and those who know that mutable shared state usually exists.
In absence of mutable shared state it is perfectly
> 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 p
On Tuesday, April 25, 2017 at 7:52:25 PM UTC-7, Dave Cheney wrote:
>
> > Yes, and then crashes the program. In the scenario I described, with
> thousands of other requests in flight that meet an abrubt end. That could
> be incredibly costly, even if it's been planned for
>
> There are a host o
> Yes, and then crashes the program. In the scenario I described, with
> thousands of other requests in flight that meet an abrubt end. That could be
> incredibly costly, even if it's been planned for
There are a host of other reasons that can take a server offline abruptly. It
seems like a od
On Tuesday, April 25, 2017 at 6:07:33 PM UTC-7, 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
>> certainl
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 th
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
On Tue, Apr 25, 2017 at 6:22 AM, Henry wrote:
> 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 th
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
27 matches
Mail list logo
