FYI, errors.Is expects to match against a value, not a type. errors.Is is useful with a value like io.EOF. It's not useful with a type like exec.ExitError. For a type, you want to use errors.As. Or, in this case, a type assertion.

@ianlancetaylor why can't errors.Is match against type as well? Using errors.As means I need to explicitly create a pointer to the error I need to check. And using errors.As wrong is a source of runtime crashes, similar to Python.

https://play.golang.org/p/Fk-hFe2Urb0

errors.Is takes a value, not a type. It's approximately the == operator. You can't write

    if err == exec.ExitError {

so you can't write

    if errors.Is(err, exec.ExitError) {

Yes, you have to call errors.As with the right kind of argument, but it's not quite a Pythonesque runtime error. Running go vet will report the problem, and go vet is run automatically whenever you run go test.

I use go run, because tests for os.exec in my scenario with wrapping administrative binaries are either dangerous or too complicated.

If you choose to write code with no tests then I suggest that you at least add go vet to your process.

Change https://golang.org/cl/213337 mentions this issue: os/exec: add examples for exec.Error and exec.ExitError