[pcwalton]

1. Errors can be problems in Go as well if they're swallowed and not handled (for example, writing "os.Chdir("/foo");" will silently cause any errors to be ignored). Note that a Java fuzzer that detects uncaught exceptions would notice a failing chdir() written in this way, while the Go fuzzer would not notice this issue.

2. In Java, it's easy to tell whether, say, an IOException was working as intended or was an actual failure. Just check whether it was caught or not. Granted, that won't handle apps that try to catch wide swathes of exception types, but Go apps can abuse Go's "recover" facility in the same way.

[jen20]

There is a useful linter named `errcheck` for Go which looks for swallowed or shadowed errors [1]. It's included in `gometalinter` [2] (which is worth running as part of the CI checks on any Go codebase).

[1] https://github.com/kisielk/errcheck [2] https://github.com/alecthomas/gometalinter

[throwawayfuzz]

Unfortunately, there are a number of correct uses of go that swallow errors. For example, fmt.Println returns an error, but you're just not going to see that error handled. Sometimes, it doesn't matter whether something has failed, because there's not a useful, proportionate thing you can do to respond to that failure. And it's not possible to know from machine examination which cases are which. I'm sure for some programs (grep?) a failure to emit a line to stdout is cause for failure. But for most it is not.

[favadi]

`errcheck` ignores unhandle error value of `fmt.Println`.

[dullgiulio]

1. One assumes that os.Chdir is used down the road. If it failed unchecked it will probably cause a panic later on when it is assumed it succeeded. And again, linters help.

2. Apart from the few functions that are only called for side effects, the others must return something. Thus ignoring errors is an explicit action.

I have seen Java apps catch swathes of exceptions more often that Go apps abuse "recover". It is this way in a lot of short examples.

[pcwalton]

> 1. One assumes that os.Chdir is used down the road. If it failed unchecked it will probably cause a panic later on when it is assumed it succeeded.

You could make the same argument about any errors being ignored. The fact is that syntax/semantics that allows any errors to be silently swallowed is suboptimal.

> 2. Apart from the few functions that are only called for side effects, the others must return something. Thus ignoring errors is an explicit action.

Ignoring errors is not always an explicit action, as you pointed out yourself. In Java, however, it is always an explicit action.

Java is simply more robust at making sure errors are handled than Go is.

[infogulch]

Re: recover: yes that's possible but I've never seen it abused like Java's `catch (Exception e) {}`.