>
> 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 originall
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:
https://blog.golang.org/errors-are-values
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
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) (
>
> 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 check/handle
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 := handle.Err
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.
>
> Ian
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(&C.struct_timespec{tv_sec: 0, t
