Re: [go-nuts] Recover considered harmful

[Kevin Conway]

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 condition that should stop
> > execution or log failure.
>
> Also a great example! The main take away here is that we should always
> design for failure, and sometimes the primary failure mode should be
> "abort at all costs and let the application developer know that
> something catastrophic happened which could lead to worse things
> happening in the future".
>
> —Sam
>

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 recovery method? The fundamental assertion being made
by panic advocates is that you know better than I when my program should
end and you want some mechanism to enforce that opinion on me.

I'll argue that sticking to idiomatic errors returned by function calls
combined with static analysis tools, like errcheck, are sufficient in
solving for all scenarios where panic might otherwise be used to signal an
error state. If you want to use panic internally within an API that's
completely acceptable so long as that panic is never exposed beyond the API
boundary. To quote the golang blog on the subject:

The convention in the Go libraries is that even when a package uses panic
internally, its external API still presents explicit error return values.

-- 
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 an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

[Sam Whited]

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.

Also a great example! The main take away here is that we should always
design for failure, and sometimes the primary failure mode should be
"abort at all costs and let the application developer know that
something catastrophic happened which could lead to worse things
happening in the future".

—Sam

-- 
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 an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

[Dan Kortschak]

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 of pharmacuetical and other health-related
technologies and worse in patient health outcome failures (also
probably in other field, but I those are outside my expertise).

For horror, see this talk https://youtu.be/7gYIs7uYbMo?t=523 (time at
point in talk where he talks about the software issues that ultimately
resulted in drug trials based on completely spurious data).

On Mon, 2017-04-24 at 08:41 -0500, Sam Whited wrote:
> 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 some reason I can't get a handle to
> urandom(4)
> I'd probably rather crash the program than risk having another
> developer ignore that error and generate keys with a zeroed IV (or
> whatever the case may be).

-- 
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 an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

[roger peppe]

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 unexpected problem.
>
> See encoding/gob/error.go for an example.
>
> More generally, recover is excellent for isolation of errors in multi-client
> servers.

I've certainly used both these techniques in the past, but I'm no longer
entirely sure whether this really is "excellent". It's so easy to have
code that relies on non-deferred cleanup of state that invokes some
code that happens to panic (whether with a known type or not), leading
to hard-to-debug problems that would have been considerably easier if
the whole thing had just crashed.

In general, the only time I'd now consider using the "panic with
identifiable type" technique is in recursive descent parsers and the
like, where the domain is severely constrained and the convenience of
being able to use the results of called functions directly is great.

That said, my most recent use was to exit early from sort.Search when an
unexpected error occurred talking to the network. Useful but arguably
a bit dirty.

  rog.

-- 
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 an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

[Sam Whited]

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 because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

[Юрий Соколов]

:-)
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 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 this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

[Jan Mercl]

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 this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

[Sam Whited]

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 some reason I can't get a handle to urandom(4)
I'd probably rather crash the program than risk having another
developer ignore that error and generate keys with a zeroed IV (or
whatever the case may be).

—Sam

-- 
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 an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

[Sokolov Yura]

понедельник, 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 not, panics again, 
> thus behaving like any other unexpected problem.
>
> See encoding/gob/error.go for an example.
>
> More generally, recover is excellent for isolation of errors in 
> multi-client servers.
>
> Even more generally, blanket statements about what to do or not do with 
> the features of a programming language are too often taken as strict rules 
> rather than thoughtful guidelines. "Don't use panic or recover" is an 
> example. Panic and recover are the perfect tools for some problem and 
> prohibiting them outright eliminates some powerful designs.
>
> -rob
>

Rob, you just described panic as an generic exception mechanism.
Then why Go has no convenient exceptions?

And what about unrecoverable panic? C-style `assert`?
`net/http` recovers from all panics currently, and it is clear design flaw.
There should be distinction between "safe to recover" errors/panics and
"have to stop execution" panics/asserts.
 

>
> On Mon, Apr 24, 2017 at 5:40 AM, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com > wrote:
>
>> 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 panic, if an API is used correctly; this includes failing 
>> syscalls that you'd expect to be correct if the API is correctly - your 
>> expectations might be wrong. Return an error on non-code related problems.
>> 3. Don't recover, pretty much universally. Even using it as a 
>> control-flow mechanism seems broken to me; it would hide actual programming 
>> errors that *should* crash
>> 4. If you are using a library that panics and you dislike that, I see two 
>> possible root-causes; a) you are using a library that badly coded 
>> (according to 2) or b) your program is buggy. In either case, the correct 
>> solution doesn't seem to paper over either bug, but to complain loudly so 
>> it gets fixed.
>> 5. Be prepared for your stuff crashing, from a dev-induced panic or a 
>> runtime-induced panic.
>>
>> And as a preventative measure: I say this as a person who was oncall 
>> while a large service, written in a memory safe language, crashed globally 
>> and took our service out. I know it's hard to be prepared for these things 
>> and to recover from them, but I *still* believe that crashing is the 
>> right thing to do. You can not prevent crashes, even globally synchronized 
>> ones, to happen. Because programmers are just humans and humans are 
>> fallible and stuff happens. You need to be prepared to deal with human 
>> failures.
>>
>> On Mon, Apr 24, 2017 at 2:24 PM, Sokolov Yura > > wrote:
>>
>>>
>>> > 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 functioning than corrupt your data further" 
>>>
>>> > It's sometimes a perfectly valid and quite reasonable approach to 
>>> defer a recover() in an API function and panic(forWhateverReason) somewhere 
>>> down the call chain.
>>> > A recursive descent parser may get much simpler and easier to code, 
>>> for example.
>>>
>>> I don't agree. I call it "abusing". In absence of other comfortable 
>>> ways, panic is abused to unwind stack fast (upto recover).
>>> I could be mistaken.
>>>
>>> -- 
>>> 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 
>>> an email to golang-nuts...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> -- 
>> 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 an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

['Axel Wagner' via golang-nuts]

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 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 example.
>
> More generally, recover is excellent for isolation of errors in
> multi-client servers.
>
> Even more generally, blanket statements about what to do or not do with
> the features of a programming language are too often taken as strict rules
> rather than thoughtful guidelines. "Don't use panic or recover" is an
> example. Panic and recover are the perfect tools for some problem and
> prohibiting them outright eliminates some powerful designs.
>
> -rob
>
>
> On Mon, Apr 24, 2017 at 5:40 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> 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 panic, if an API is used correctly; this includes failing
>> syscalls that you'd expect to be correct if the API is correctly - your
>> expectations might be wrong. Return an error on non-code related problems.
>> 3. Don't recover, pretty much universally. Even using it as a
>> control-flow mechanism seems broken to me; it would hide actual programming
>> errors that *should* crash
>> 4. If you are using a library that panics and you dislike that, I see two
>> possible root-causes; a) you are using a library that badly coded
>> (according to 2) or b) your program is buggy. In either case, the correct
>> solution doesn't seem to paper over either bug, but to complain loudly so
>> it gets fixed.
>> 5. Be prepared for your stuff crashing, from a dev-induced panic or a
>> runtime-induced panic.
>>
>> And as a preventative measure: I say this as a person who was oncall
>> while a large service, written in a memory safe language, crashed globally
>> and took our service out. I know it's hard to be prepared for these things
>> and to recover from them, but I *still* believe that crashing is the
>> right thing to do. You can not prevent crashes, even globally synchronized
>> ones, to happen. Because programmers are just humans and humans are
>> fallible and stuff happens. You need to be prepared to deal with human
>> failures.
>>
>> On Mon, Apr 24, 2017 at 2:24 PM, Sokolov Yura 
>> wrote:
>>
>>>
>>> > 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 functioning than corrupt your data further"
>>>
>>> > It's sometimes a perfectly valid and quite reasonable approach to
>>> defer a recover() in an API function and panic(forWhateverReason) somewhere
>>> down the call chain.
>>> > A recursive descent parser may get much simpler and easier to code,
>>> for example.
>>>
>>> I don't agree. I call it "abusing". In absence of other comfortable
>>> ways, panic is abused to unwind stack fast (upto recover).
>>> I could be mistaken.
>>>
>>> --
>>> 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
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> 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 an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

[Rob 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 not, panics again,
thus behaving like any other unexpected problem.

See encoding/gob/error.go for an example.

More generally, recover is excellent for isolation of errors in
multi-client servers.

Even more generally, blanket statements about what to do or not do with the
features of a programming language are too often taken as strict rules
rather than thoughtful guidelines. "Don't use panic or recover" is an
example. Panic and recover are the perfect tools for some problem and
prohibiting them outright eliminates some powerful designs.

-rob


On Mon, Apr 24, 2017 at 5:40 AM, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> 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 panic, if an API is used correctly; this includes failing
> syscalls that you'd expect to be correct if the API is correctly - your
> expectations might be wrong. Return an error on non-code related problems.
> 3. Don't recover, pretty much universally. Even using it as a control-flow
> mechanism seems broken to me; it would hide actual programming errors that
> *should* crash
> 4. If you are using a library that panics and you dislike that, I see two
> possible root-causes; a) you are using a library that badly coded
> (according to 2) or b) your program is buggy. In either case, the correct
> solution doesn't seem to paper over either bug, but to complain loudly so
> it gets fixed.
> 5. Be prepared for your stuff crashing, from a dev-induced panic or a
> runtime-induced panic.
>
> And as a preventative measure: I say this as a person who was oncall while
> a large service, written in a memory safe language, crashed globally and
> took our service out. I know it's hard to be prepared for these things and
> to recover from them, but I *still* believe that crashing is the right
> thing to do. You can not prevent crashes, even globally synchronized ones,
> to happen. Because programmers are just humans and humans are fallible and
> stuff happens. You need to be prepared to deal with human failures.
>
> On Mon, Apr 24, 2017 at 2:24 PM, Sokolov Yura 
> wrote:
>
>>
>> > 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 functioning than corrupt your data further"
>>
>> > It's sometimes a perfectly valid and quite reasonable approach to defer
>> a recover() in an API function and panic(forWhateverReason) somewhere down
>> the call chain.
>> > A recursive descent parser may get much simpler and easier to code, for
>> example.
>>
>> I don't agree. I call it "abusing". In absence of other comfortable ways,
>> panic is abused to unwind stack fast (upto recover).
>> I could be mistaken.
>>
>> --
>> 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 an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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 an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

[Sokolov Yura]

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's example)
- I may give to programmer "low level" interface with access to internals 
(for performance).
  If programmer uses it in a wrong way, and my library's code detected that 
(but too late
  to return error, probably, by founding broken invariants), then it is 
clearly better to stop
  functioning.

In both cases I need a way stop process, and `panic` is a most clear way to 
do that...
if no one calls `recover`.

понедельник, 24 апреля 2017 г., 15:40:36 UTC+3 пользователь Kevin Conway 
написал:
>
> > 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 provide me all the tools 
> necessary to make the right decision (such as custom error references or 
> types) but never to make the decision for me.
>
> I've yet to find a panic that would not be better served as a returned 
> error.
>
> On Mon, Apr 24, 2017 at 7:24 AM Sokolov Yura  > wrote:
>
>>
>> > 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 functioning than corrupt your data further" 
>>
>> > It's sometimes a perfectly valid and quite reasonable approach to defer 
>> a recover() in an API function and panic(forWhateverReason) somewhere down 
>> the call chain.
>> > A recursive descent parser may get much simpler and easier to code, for 
>> example.
>>
>> I don't agree. I call it "abusing". In absence of other comfortable ways, 
>> panic is abused to unwind stack fast (upto recover).
>> I could be mistaken.
>>
>

-- 
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 an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

['Axel Wagner' via golang-nuts]

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 panic, if an API is used correctly; this includes failing
syscalls that you'd expect to be correct if the API is correctly - your
expectations might be wrong. Return an error on non-code related problems.
3. Don't recover, pretty much universally. Even using it as a control-flow
mechanism seems broken to me; it would hide actual programming errors that
*should* crash
4. If you are using a library that panics and you dislike that, I see two
possible root-causes; a) you are using a library that badly coded
(according to 2) or b) your program is buggy. In either case, the correct
solution doesn't seem to paper over either bug, but to complain loudly so
it gets fixed.
5. Be prepared for your stuff crashing, from a dev-induced panic or a
runtime-induced panic.

And as a preventative measure: I say this as a person who was oncall while
a large service, written in a memory safe language, crashed globally and
took our service out. I know it's hard to be prepared for these things and
to recover from them, but I *still* believe that crashing is the right
thing to do. You can not prevent crashes, even globally synchronized ones,
to happen. Because programmers are just humans and humans are fallible and
stuff happens. You need to be prepared to deal with human failures.

On Mon, Apr 24, 2017 at 2:24 PM, Sokolov Yura 
wrote:

>
> > 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 functioning than corrupt your data further"
>
> > It's sometimes a perfectly valid and quite reasonable approach to defer
> a recover() in an API function and panic(forWhateverReason) somewhere down
> the call chain.
> > A recursive descent parser may get much simpler and easier to code, for
> example.
>
> I don't agree. I call it "abusing". In absence of other comfortable ways,
> panic is abused to unwind stack fast (upto recover).
> I could be mistaken.
>
> --
> 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 an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

[Ian Davis]

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 :> > The process continues up 
> the stack until all functions in the
> > current goroutine have returned, at which point the program crashes

The standard library uses panic in a couple of places to exit from
deeply nested function calls, e.g.
https://github.com/golang/go/blob/master/src/encoding/json/decode.go#L167
A while ago I wrote this usage up as a recipe:
https://github.com/iand/gocookbook/blob/master/recipes/panic-for-deep-errors.md
Ian



-- 
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 an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

[Kevin Conway]

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 current
goroutine have returned, at which point the program crashes

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. The recover() builtin
must exist to account for the fact that _all_ uses of panic in user space
are, in fact, recoverable errors.

As someone developing in go, it is infuriating when external libraries
(whether 3rd party or std lib) make decisions about when my program should
stop. Code related bugs, such as nil pointer dereferences or invalid
interface conversions, should result in a process failure just like a
segfault in any other runtime. However, some library using the same process
ending mechanism to let me know that it doesn't like the format of my
string input is unacceptable.

On Mon, Apr 24, 2017 at 5:41 AM Christian von Pentz 
wrote:

> 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 external tools/libraries
> which were completely "fine" to recover from. magicmime was such a
> package that had a few "hiccups" when used in a multi-threaded
> environment mostly due to the underlying libmagic. That being said, very
> easy and convenient to recover from, so yeah, I would say recover is a
> perfectly valid strategy sometimes.
>
> --
> 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 an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Recover considered harmful

[Christian von Pentz]

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 external tools/libraries
which were completely "fine" to recover from. magicmime was such a
package that had a few "hiccups" when used in a multi-threaded
environment mostly due to the underlying libmagic. That being said, very
easy and convenient to recover from, so yeah, I would say recover is a
perfectly valid strategy sometimes.

-- 
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 an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Recover considered harmful

[Sokolov Yura]

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. So, is there reason to recover at all?

Also, presence of `recover` complicates implementation of `defer`.
I believe, it could be optimized much harder in absence of `recover`
(i.e. if program always exits on panic).

I could be mistaken.

Yura.

-- 
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 an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.