Re: [go-nuts] Error handling

2021-02-25 Thread Michael MacInnis
> > I realize that this thread ended up diverging into a wider discussion of > exceptions and error handling in general but I wanted mention one of the > problems I discovered and maybe a potential solution for others who may be > tempted to play around with something like this. > > I

Re: [go-nuts] Error handling

2021-02-20 Thread Michael MacInnis
I don't believe anyone is talking about not handling errors. There are functions that perform a sequence of actions and need to go no further when an error is encountered. An example of this type of function is presented in the "Errors are Values" post:

Re: [go-nuts] Error handling

2021-02-20 Thread Michael MacInnis
Neat. What you and I are doing is very similar. Particularly how the handler is "bound" to the error and checks to make sure that the error is non-nil before attempting to recover. The differences I see in our approaches are as follows: I support wrapping an error or performing some arbitrary

Re: [go-nuts] Error handling

2021-02-18 Thread Michael MacInnis
At the risk of getting caught in the crossfire, I will point out again that I just found it interesting how close it was possible to get to something like check/handle with just standard language constructs. If you'll excuse the cuddled checks, I think this: func CopyFile(src, dst string)

Re: [go-nuts] Error handling

2021-02-15 Thread Michael MacInnis
> > Go helps with that. Even team's proposal was finally retracted: > https://github.com/golang/go/issues/32437 Discussion there is lengthy, > but worth > reading to sense why wider community considers "boilerplate" as asset. > Thanks, I did follow the try proposal and the earlier

[go-nuts] Error handling

2021-02-13 Thread Michael MacInnis
I've been playing around with reducing error handling boilerplate using standard language constructs. I'm currently doing something that looks like this: import ( "github.com/michaelmacinnis/handle" ) func do(name string) (err error) { check, handle :=

Re: [go-nuts] Surprising number of threads

2018-11-01 Thread Michael MacInnis
On Thursday, November 1, 2018 at 12:20:39 PM UTC-4, Ian Lance Taylor wrote: > > > Every blocking cgo call requires a thread. Also every Go program has > a supporting thread that monitors the programs. If you see only 4 > threads for that program then I think we're doing pretty well. > >

[go-nuts] Surprising number of threads

2018-11-01 Thread Michael MacInnis
While running a Go program that uses Cgo, I noticed a surprising number of threads. I believe the code below demonstrates what I'm seeing minus (what I hope are) extraneous details. package main // #include import "C" func main() { for { C.nanosleep(_timespec{tv_sec: 0, tv_nsec: