114e85c200
Since we are now building on Go 1.11 (as of 074a2d4f (all: use Go 1.11
in CI, 2018-08-28)) and Go 1.11 supports Go Modules [1], let's stop
using Glide, and begin using Go Modules.
This involves a few things:
* Teach the Makefile how to build go.sum files instead of glide.lock
files.
* Teach continuous integration services to build Git LFS in a
non-$GOPATH environment, since (without setting GO111MODULE=on
explicitly, which we choose not to do), this will break compiling
Git LFS, because Go 1.11 will ignore modules present in a Go
checkout beneath $GOPATH.
* In order to do the above, let's also make sure that we are
un-setting $GOCACHE in the environment, as this causes Go to work
without modules support [2].
* Because we're no longer building in a `$GOPATH`-based location,
let's instruct the CircleCI base image to archive the new location,
too.
* Similarly, teach the RPM spec to build in a non-$GOPATH location.
* By contrast, since we use dh_golang to build git-lfs binaries on
Debian, let's wait until the upstream dh_golang package is released
with support for Go 1.11 module support explicitly. Therefore, force
GO111MODULE to be on so that we can build a copy of Git LFS whose
checkout is within a $GOPATH.
Although the go.mod versions match the glide.yaml ones, the diff
attached is large because Go Modules do not vendor `_test.go` files,
whereas Glide does.
[1]: https://golang.org/doc/go1.11#modules
[2]: `GOCACHE=on` will be deprecated in Go 1.12, so this change makes
sense for that reason, too.
Co-authored-by: brian m. carlson <bk2204@github.com>
|
||
|---|---|---|
| .. | ||
| .gitignore | ||
| .travis.yml | ||
| appveyor.yml | ||
| errors.go | ||
| LICENSE | ||
| README.md | ||
| stack.go | ||
errors 
Package errors provides simple error handling primitives.
go get github.com/pkg/errors
The traditional error handling idiom in Go is roughly akin to
if err != nil {
return err
}
which applied recursively up the call stack results in error reports without context or debugging information. The errors package allows programmers to add context to the failure path in their code in a way that does not destroy the original value of the error.
Adding context to an error
The errors.Wrap function returns a new error that adds context to the original error. For example
_, err := ioutil.ReadAll(r)
if err != nil {
return errors.Wrap(err, "read failed")
}
Retrieving the cause of an error
Using errors.Wrap constructs a stack of errors, adding context to the preceding error. Depending on the nature of the error it may be necessary to reverse the operation of errors.Wrap to retrieve the original error for inspection. Any error value which implements this interface can be inspected by errors.Cause.
type causer interface {
Cause() error
}
errors.Cause will recursively retrieve the topmost error which does not implement causer, which is assumed to be the original cause. For example:
switch err := errors.Cause(err).(type) {
case *MyError:
// handle specifically
default:
// unknown error
}
Read the package documentation for more information.
Contributing
We welcome pull requests, bug fixes and issue reports. With that said, the bar for adding new symbols to this package is intentionally set high.
Before proposing a change, please discuss your change by raising an issue.
Licence
BSD-2-Clause