Re: [go-nuts] Re: Recover considered harmful

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

Re: [go-nuts] Recover considered harmful

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

[go-nuts] Re: Recover considered harmful

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

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 code > > that will blithely continue after an error

Re: [go-nuts] doubt about sync.NewCond

Got it. Thank you. 在 2017年4月22日星期六 UTC+8上午9:52:45，Matt Harden写道： > > There is no guarantee that any of your goroutines will execute even > Lock(), much less Wait(), before the main goroutine executes Broadcast(). > > On Thu, Apr 20, 2017 at 8:39 PM Allan > > wrote: > >> I run a demo program to l

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 stop > execution or log failure. A

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 (mis)development

Re: [go-nuts] Set a SAN otherName using `x509.CertificateRequest`

Yes, but not as easily as using DNSName. You need to add the extension "manually". Put it in ExtraExtensions of the template. See /usr/local/go/src/crypto/x509/x509.go functions buildExtensions and marshalSANs to see how to put it there. Janne Snabb sn...@epipe.com On 2017-04-24 18:28, Adam Med

[go-nuts] gopacket.Newpacket does not provide MetaData for the new packet??

Hi, all, I am trying to capture a GRE tunneled packet and get rid off the GRE header to retrieve the encapsulated packet. The code is quite simple, I basically grabs the GRE tunneled packet and build a new one from its payload. The problem I have here is the MetaData of the packet1 channel is

[go-nuts] Re: [Help] Seeing an occasional data race on a closed channel

Hi Owen, On Monday, April 24, 2017 at 1:23:58 PM UTC-5, Owen Waller wrote: > > My understanding is that when a key is pressed that will terminate the > program. This closes the quit channel, which causes the deferred > closeChans() to be called. That in turn closes the done and the bus > chann

[go-nuts] [Help] Seeing an occasional data race on a closed channel

after calling canceled, but before sending on bus, you can close the channels. Put i in one select: select { case <-done: default: select { case <-done: case bus<-r: } } -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe

[go-nuts] 'Go install' fail to import package with 'Docker run'

The symptom is that a single command docker run go install would fail at importing Go packages, but running them separately, i.e. docker run -it bash (with the source files copied over to same location) go install would work just fine. Details below: - The build comman

Re: [go-nuts] Recover considered harmful

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

Re: [go-nuts] Re: Semicolons in Go

Ian, thank you for the thoughtful reply. I realized that my last post might have sounded like I was criticizing your post and that definitely wasn't the intention. My apologies. On Monday, April 24, 2017 at 10:48:25 AM UTC-4, Ian Davis wrote: > > With respect, you are tilting at windmills. You r

[go-nuts] [Help] Seeing an occasional data race on a closed channel

Hi All, I am stumped by this one, so I am hoping that someone on the list can spot the bug in this piece of code. The code is here: https://play.golang.org/p/c3356cVtWa The code occasionally (roughly 1 in 10 to 1 in 5 on my hardware) fails with the data race shown below. The code uses a fairly

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 > behaving like any other u

[go-nuts] Extensible markdown library

Hi, I'm rather new to Go and for a toy project, I would need to extend markdown with custom syntax. For example "{key: 123}" should be parsed and handled in a special way, so that I can access all occurrences of keys and ids after the transformation. I found that there are different markdown l

[go-nuts] Set a SAN otherName using `x509.CertificateRequest`

Is it possible to set a SAN otherName in x509.CertificateRequest structure, so it will be present in the DER encoded output of x509.CreateCertificateRequest ? -- You received

[go-nuts] [ANN] 2nd Call for Papers: 16th ACM SIGPLAN Erlang Workshop 2017

Technical, practice, and application papers related to Go are welcome and encouraged! 2nd CALL FOR PAPERS === Sixteenth ACM SIGPLAN Erlang Workshop http://erlang.org/workshop/2017/ --- Oxford, United Kingdom, 8 September 2017 S

[go-nuts] Dynamic type assertion for interface

Please do note that the structs in this example is a sample.My struct is complex than this. https://play.golang.org/p/_t7gx3javb Here I have a function where i will be using lot of times.Each time i will be passing object of different struct types.So i use the parameter arguments as interface{}

Re: [go-nuts] https://go-proverbs.github.io/ what do you think of this one ?

On Mon, Apr 24, 2017 at 4:39 PM wrote: > Any thoughts? Yes. In the second version there is something that can be withdrawn. The special case of handling an error value, which is just an interface value like many other interface values. Getting rid of that special case and the special syntax for

Re: [go-nuts] Re: Semicolons in Go

Please don't feed this troll. On Mon, Apr 24, 2017 at 10:42 AM, wrote: > One of the things that I learned early in life is to recognize B.S. when I > see it. My B.S. flag went up first when I read where someone claimed that > "artifacts" are bad and detract from the readability of code. A compac

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 received this message becaus

Re: [go-nuts] Re: Semicolons in Go

I won't. I'm done with this thread. On Mon, Apr 24, 2017 at 10:52 AM David Peacock wrote: > Please don't feed this troll. > > On Mon, Apr 24, 2017 at 10:42 AM, wrote: > >> One of the things that I learned early in life is to recognize B.S. when >> I see it. My B.S. flag went up first when I rea

Re: [go-nuts] Re: Semicolons in Go

With respect, you are tilting at windmills. You replied to an 8 year old post from the design phase of the language. It's now 2017 and no-one wants to step back in time to change what has turned out to be a very successful design. You stated in your first message that you "simply won't use the lang

Re: [go-nuts] Re: Semicolons in Go

One of the things that I learned early in life is to recognize B.S. when I see it. My B.S. flag went up first when I read where someone claimed that "artifacts" are bad and detract from the readability of code. A compact and well-defined artifact, like the semicolon, makes code *more* readable

[go-nuts] https://go-proverbs.github.io/ what do you think of this one ?

Perfection is attained, not when there is nothing more to add, but when there is nothing more to be withdrawn. somehow relates to https://www.youtube.com/watch?v=rFejpH_tAHM If i just try to think to apply it to this code sample func getCwd() (string, error) { cwd, err := os.Getwd()

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 o

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" group. To unsubscribe from

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 exception is security issues. If for

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 identifiable type and

Re: [go-nuts] Re: Semicolons in Go

The person who resurrected this years-old post is ignoring the fundamental point that one's individual preference is irrelevant in matters of readability. What matters is consistently applied convention throughout the community. As the proverb goes, Gofmt's style is no one's favorite, yet gofmt is

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 an

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 Axel'

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

> 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

Re: [go-nuts] Recover considered harmful

> 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

Re: [go-nuts] Recover considered harmful

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

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 externa

[go-nuts] Re: Turning unicode code string to rune

See: https://golang.org/pkg/unicode/utf8/#DecodeRuneInString On Saturday, 22 April 2017 19:51:09 UTC+1, Tong Sun wrote: > > Hi, > > Given a unicode code string, be it "4e16", or "0x4e16", or "u4e16", how to > turn it into a single char rune? > > You can finish the code at https://play.golang.org

[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 corruption.

Re: [go-nuts] What's the recommended way to determine if a type.Type is exported?

Alternatively, if you are walking an AST and only interested in the exported names then you can use https://golang.org/pkg/go/ast/#PackageExports . It will filter your tree to only elements that are exported before you begin traversal. As to your specific case of determining if a type used in a me

Re: [go-nuts] What's the recommended way to determine if a type.Type is exported?

Agreed! I ended up casting to types.NamedType (or pointer then elem())... I'll try your method too! On Sun, Apr 23, 2017 at 11:11 PM Axel Wagner wrote: > I'd say, probably type-asserting to a *types.TypeName > and then use Exported() >

Re: [go-nuts] Re: Semicolons in Go

On 22 April 2017 at 02:59, Matt Harden wrote: > a = ( b > + c > + d > * e > ) That doesn't work: https://play.golang.org/p/z6HFDK3XRT The usual Go idiom is to leave the operators at the end of the lines: a = b + c + d*