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
>
> 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
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
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
>
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
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
> 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
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
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 -
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
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
`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
> 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
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
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
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
16 matches
Mail list logo