[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

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

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

[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

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

[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

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

[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

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 >

[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

[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

[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] 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

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

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

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] 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.

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

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

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

[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

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

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

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 +