Wednesday, 24 June 2020

Go Language: Errors


errors (standard package)

errors - The Go Programming Language

Go by Example: Errors

If function returns type error and we want to return error object with custom message:

return errors.New("Argument is nil: file")

To create an error with formatted message use fmt.Errorf:

err := fmt.Errorf("user %q (id %d) not found", name, id)


Example when type assertion is used to convert from error to some specific error type:
What is err.(*os.PathError) in Go?

Example:

fi, err := file.Stat()
if err != nil {
return 0, fmt.Errorf("Failed to access file %s", (err.(*os.PathError)).Path)
}


github.com/pkg/errors package


Go default package "errors" does not support capturing stack trace info at the moment when error is created. When the error is created somewhere deep on the stack, it can be returned from the chain of function calls to the main error handler where the only information which can be extracted is error text message, without its context. When such message appears in the log, it is difficult to find out where it came from, from which function. 

Example of the Go app log snippet:

...
Error: Bad status: 404 Not Found
Terminating with error: 1
Process exited with code 1


All we know from error message "Bad status: 404 Not Found" that some HTTP response returned 404 but we don't know which one and in which part of the code.

To capture stack trace at the moment when error gets created and later be able to print it out, we can use github.com/pkg/errors package.

errors package · pkg.go.dev

This article explains best practices and how you need to change our code in order to use this package efficiently:




Here are the changes in the code base that need to be done when switching from errors to github.com/pkg/errors package:

import (
"errors"
...
)

will be replaced with 

import (
        ...
"github.com/pkg/errors"
)

...so go.mod will contain something like:

github.com/pkg/errors v0.8.1


Error creation errors.New("...") will remain the same but 

fmt.Errorf("%s value is empty string", key)

will be replaced with 

errors.Errorf("%s value is empty string", key)


Instead of passing the original error and message:

if err := bg.foo(br, df); err != nil {
return err
}

...we can add a context info by adding a contextual error message (and still keeping the original one):

if err := bg.foo(br, df); err != nil {
return errors.Wrapf(err, "Fetching resource with ID = %s failed for entity with ID = %s", br.ResID, br.ID)
}


Instead of just printing the error message:

func LogAndExit(err error, code int) {
if err != nil {
log.Printf("Error: %s\nTerminating with error: %d", err.Error(), code)
os.Exit(code)
}
}

we can now print message AND stack trace:
 
func LogAndExit(err error, code int) {
if err != nil {
log.Printf("Error: %+v\nTerminating with error: %d", err, code)
os.Exit(code)
}
}

Monday, 15 June 2020

Go Linters in VS Code

If you are using VS Code for Go development, you have probably installed Go for Visual Studio Code extension. It allows configuring a linter of choice by going to settings (CTRL+,), typing go.lintTool and selecting a desired linter:



golint


golint is a default linter. To run it across all files in the project, execute this from the project's root directory:

$ golint ./...

For each issue detected, golint's output contains source code file name, line and column numbers and the linter message.

When I run golint on one of my projects that I used for benchmark, it found 9 issues.



Staticcheck


Staticcheck is an advanced linter. VS Code Go extension can install it automatically if we select staticcheck as go.lintTool value and opt to install it in the popup notification that will apper upon selection:


Installation log can be verified in the output window:


To run it across all files in the project, execute this from the project's root directory:

$ staticcheck ./...

Similar to golinit, for each issue detected the output contains source code file name, line and column numbers and the linter message.

When I run Staticcheck on my benchmark project, it found 57 issues.

Static check's repo is at https://github.com/dominikh/go-tools and shows active development. At the time of writing has 72 watchers, 3.2k stars and 199 forks.

revive


revive is another Go linting tool which is listed among other linters in the default linters list in go.lintTools:



Installation output log:




To run it across all files in the project, execute this from the project's root directory:

$ revive ./...

Similar to golinit, for each issue detected the output contains source code file name, line and column numbers and the linter message.

When I run revive on my benchmark project, it found 11 issues.

Revive repo is at https://github.com/mgechev/revive and shows active development. At the time of writing has 29 watchers, 2.3k stars and 107 forks.


golangci-lint


golangci-lint is a Go linters aggregator which currently includes 48 linters. Some are enabled by default (e.g. staticcheck) and some are not. There is no need to install all linters, this tool does it all, just select golangci-lint as go.lintTool value:




Installation log output:



To run it across all files in the project, execute this from the project's root directory:

$ golangci-lint run

The output is more verbose, in addition to source code file name, line and column numbers, for each issue detected golangci-lint also prints that code line with a caret that shows exact character in line for which the linter message is issued. All messages are coloured.

When I run golangci-lint on my benchmark project, it found the same number of issues as Staticcheck. When compared the output, I found that issues reported were mostly the same as those from Staticcheck but were reported as the catch of some other enabled linters (e.g. gosimple, govet, deadcheck, unused etc...).

golangci-lint repo is at https://github.com/golangci/golangci-lint and shows active development. At the time of writing has 77 watchers, 5.5k stars and 495 forks.


Conclusion


Given the more complete and verbose output and larger community around the project, I would opt for using golangci-lint as the preferred Go linting tool.