Good day, people.
Title is a bit controversial :-)
I want to ask:
- how useful `recover` for you?
- Don't you think it is a bit "dangerous"?
I mean: panic usually means programmer error, so if it happens, then
program behaves incorrectly, and there is always a chance of serious
state corruption.
Aside from arguments about using panic/recover to simulate longjmp inside
recursive descent parsers I can think of no valid reason why recover should be
used in production code.
Imo, the arguments about wrapping all goroutines in a catch all recover are
solving th wrong problem.
- if third p
On 04/24/2017 11:02 AM, Sokolov Yura wrote:
> I mean: panic usually means programmer error, so if it happens, then
> program behaves incorrectly, and there is always a chance of serious
> state corruption. So, is there reason to recover at all?
I encountered many cases of panics when using externa
I'd say that recover() is not a problem but, instead, a symptom of panic()
being available to developers. I'd flip the title and say panic() should be
considered harmful. To quote from
https://blog.golang.org/defer-panic-and-recover :
> The process continues up the stack until all functions in the
On Mon, 24 Apr 2017, at 12:06 PM, Kevin Conway wrote:
> I'd say that recover() is not a problem but, instead, a symptom of
> panic() being available to developers. I'd flip the title and say
> panic() should be considered harmful. To quote from
> https://blog.golang.org/defer-panic-and-recover :> >
On Mon, Apr 24, 2017 at 1:06 PM Kevin Conway
wrote:
> Any code that invokes panic is very clearly stating that an error has
occurred that is completely unrecoverable and the _only_ choice of action
that could possibly be taken is to end the program.
It's sometimes a perfectly valid and quite rea
> Notice that real unrecoverable errors are not subject to defer/recover()
at all.
If so, then how should I raise unrecoverable error, if I really know that
it is unrecoverable?
>
> Something like C style assert(): "guy, something goes completely wrong,
and it is
much better to stop functionin
> If so, then how should I raise unrecoverable error, if I really know that
it is unrecoverable?
I don't believe you can ever know whether an error in your library is truly
unrecoverable by the process executing the code. As a someone writing and
operating the process, I'd expect a library to prov
My 2¢:
1. panic if an API is clearly used wrongly. If a dev chose to not read the
docs for this one function and ignore how it's supposed to be called, then
what else have they not read the docs of? If you can detect that a program
is incorrect, failing loudly seems the right thing to do
2. Do not
Fully agree with Axel Wagner.
- I may make mistake in my library, ie my code found that some invariant is
broken.
If library is a "shared state manager" (for example, in-memory db, or on
disk db),
then I clearly have to stop whole process instead of continue to corrupt
data
(same as Axel'
Your point 3 misses an important practical detail. Packages that use
recover internally call panic with an identifiable type and the recover
code checks whether the type is the expected one and, if not, panics again,
thus behaving like any other unexpected problem.
See encoding/gob/error.go for an
True, I genuinely missed that possibility (I always forget that panic is
perfectly well-behaved when re-panicing).
On Mon, Apr 24, 2017 at 3:09 PM, Rob Pike wrote:
> Your point 3 misses an important practical detail. Packages that use
> recover internally call panic with an identifiable type and
понедельник, 24 апреля 2017 г., 16:09:56 UTC+3 пользователь Rob 'Commander'
Pike написал:
>
> Your point 3 misses an important practical detail. Packages that use
> recover internally call panic with an identifiable type and the recover
> code checks whether the type is the expected one and, if
On Mon, Apr 24, 2017 at 7:39 AM, Kevin Conway
wrote:
> I've yet to find a panic that would not be better served as a returned
> error.
While I generally agree with you, panics in libraries should probably
not bubble up to anythihng outside of the library, the exception is
security issues. If for
On Mon, Apr 24, 2017 at 3:19 PM Sokolov Yura wrote:
> And what about unrecoverable panic? C-style `assert`?
fmt.Fprintf(os.Stderr, "it's full of stars!\n")
os.Exit(1)
--
-j
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from
:-)
Does os.Exit(1) prints backtrace of all goroutines like unrecovered panic
does?
2017-04-24 16:53 GMT+03:00 Jan Mercl <0xj...@gmail.com>:
> On Mon, Apr 24, 2017 at 3:19 PM Sokolov Yura
> wrote:
>
> > And what about unrecoverable panic? C-style `assert`?
>
> fmt.Fprintf(os.Stderr, "it's full o
On Mon, Apr 24, 2017 at 9:30 AM, Юрий Соколов wrote:
> :-)
> Does os.Exit(1) prints backtrace of all goroutines like unrecovered panic
> does?
import "runtime/debug"
fmt.Fprintf(os.Stderr, "it's full of stars!\n")
debug.PrintStack()
os.Exit(1)
--
You received this message becaus
On 24 April 2017 at 14:09, Rob Pike wrote:
> Your point 3 misses an important practical detail. Packages that use recover
> internally call panic with an identifiable type and the recover code checks
> whether the type is the expected one and, if not, panics again, thus
> behaving like any other u
On Mon, Apr 24, 2017 at 3:09 PM Rob Pike wrote:
> Your point 3 misses an important practical detail. Packages that use
> recover internally call panic with an identifiable type and the recover
> code checks whether the type is the expected one and, if not, panics again,
> thus behaving like any o
We (gonum) would extend the security exception to include scientific
code; there are far too many peer reviewed works that depend on code
that will blithely continue after an error condition that should stop
execution or log failure. These can and do end up contributing to costs
of (mis)development
On Mon, Apr 24, 2017 at 6:31 PM, Dan Kortschak
wrote:
> We (gonum) would extend the security exception to include scientific
> code; there are far too many peer reviewed works that depend on code
> that will blithely continue after an error condition that should stop
> execution or log failure.
A
On Mon, Apr 24, 2017, 21:31 Sam Whited wrote:
> On Mon, Apr 24, 2017 at 6:31 PM, Dan Kortschak
> wrote:
> > We (gonum) would extend the security exception to include scientific
> > code; there are far too many peer reviewed works that depend on code
> > that will blithely continue after an error
On Tue, Apr 25, 2017 at 5:06 AM, Kevin Conway
wrote:
> In this example we're considering panic as a mechanism of preventing
> otherwise avoidable code bugs. What happens when the same code begins
> silencing panics and continuing on? Do we add a new level of panic that
> overcomes the normal reco
On Mon, Apr 24, 2017 at 10:06 PM, Kevin Conway
wrote:
> In this example we're considering panic as a mechanism of preventing
> otherwise avoidable code bugs. What happens when the same code begins
> silencing panics and continuing on?
Then the application author has explicitly said "I don't care
As Rob Pike said, if you don't let the real reason behind "panicing" die,
then recovering is most logical thing to do in times of dire need!
For instance, the Caddy server routinely uses *recover* to recover from
panics but responsibily logs them during ServeHTTP because it has to
provide ultimate
On Tue, 2017-04-25 at 03:06 +, Kevin Conway wrote:
> The convention in the Go libraries is that even when a package uses
> panic internally, its external API still presents explicit error
> return values.
reflect?
All rules are wrong.
--
You received this message because you are subscribed
On 04/24/2017 11:02 AM, Sokolov Yura wrote:
> Good day, people.
>
> Title is a bit controversial :-)
>
> I want to ask:
> - how useful `recover` for you?
> - Don't you think it is a bit "dangerous"?
>
> I mean: panic usually means programmer error,
I don"t know what you mean saying that any pani
27 matches
Mail list logo
