Re: [go-nuts] Recover considered harmful

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

Re: [go-nuts] Recover considered harmful

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

Re: [go-nuts] Recover considered harmful

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

Re: [go-nuts] Recover considered harmful

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 >

Re: [go-nuts] Recover considered harmful

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

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`? > >

Re: [go-nuts] Recover considered harmful

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"

Re: [go-nuts] Recover considered harmful

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

Re: [go-nuts] Recover considered harmful

понедельник, 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

Re: [go-nuts] Recover considered harmful

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

Re: [go-nuts] Recover considered harmful

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

Re: [go-nuts] Recover considered harmful

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

Re: [go-nuts] Recover considered harmful

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

Re: [go-nuts] Recover considered harmful

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 :>

Re: [go-nuts] Recover considered harmful

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

Re: [go-nuts] Recover considered harmful

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

[go-nuts] Recover considered harmful

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