HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
kisielk
errcheck
Go2013–2025
kisielk / errcheck

errcheck

errcheck checks that you checked errors.

27Distinct people
33Mentions
0Explicit recommenders
2.5KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

errcheck checks that you checked errors.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year33 dated mentions

Observed mentions: 2013-06-02 16:02:43 UTC to 2025-06-04 16:18:14 UTC.

02462013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC404
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC606
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC404
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC303
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC404
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
errcheck errcheck finds silently ignored errors in Go code. For all callables that are not in the excluded list, all returned errors must be either assigned to a variable or explicitly discarded by being assigned to _. Please note that errcheck does not do any further analysis on assigned errors. For example, it will not complain about this: err := foo() // First error is discarded err = bar() if err != nil { ... } For such analysis and more, please see staticcheck. Install go install github.com/kisielk/errcheck@latest errcheck requires Go 1.25 or newer. Use For basic usage, just give the package path of interest as the first argument: errcheck github.com/kisielk/errcheck/testdata To check all packages beneath the current directory: errcheck ./... Or check all packages in your $GOPATH and $GOROOT: errcheck all errcheck also recognizes the following command-line options: The -tags flag takes a space-separated list of build tags, just like go build. If you are using any custom build tags in your code base, you may need to specify the relevant tags here. The -asserts flag enables checking for ignored type assertion results. It takes no arguments. The -blank flag enables checking for assignments of errors to the blank identifier. It takes no arguments. The -abspath flag prints the absolute paths to files with unchecked errors. The -mod flag sets the module download mode to use: readonly or vendor. The -version flag prints the version of errcheck and exits. go/analysis The package provides Analyzer instance that can be used with go/analysis API. Currently supported flags are blank, assert, exclude, and excludeonly. Just as the API itself, the analyzer is experimental and may change in the future. Excluding functions Use the -exclude flag to specify a path to a file containing a list of functions to be excluded. errcheck -exclude errcheck_excludes.txt path/to/package The file should contain one function signature per line. The format for function signatures is package.FunctionName while for methods it's (package.Receiver).MethodName for value receivers and (*package.Receiver).MethodName for pointer receivers. If the function name is followed by string of form (TYPE), then the the function call is excluded only if the type of the first argument is TYPE. It also accepts a special suffix (os.Stdout) and (os.Stderr), which excludes the function only when the first argument is a literal os.Stdout or os.Stderr. An example of an exclude file is: io.Copy(*bytes.Buffer) io.Copy(os.Stdout) os.ReadFile // Sometimes we don't care if a HTTP request fails. (*net/http.Client).Do By default, the exclude list is combined with an internal list for functions in the Go standard library that have an error return type but are documented to never return an error. To disable the built-in exclude list, pass the -excludeonly flag. Run errcheck in -verbose mode to see the resulting list of added excludes. When using vendored dependencies, specify the full import path. For example: Your project's import path is example.com/yourpkg You've vendored example.net/fmt2 as vendor/example.net/fmt2 You want to exclude fmt2.Println from error checking In this case, add this line to your exclude file: example.com/yourpkg/vendor/example.net/fmt2.Println Empty lines and lines starting with // are ignored. The deprecated method The -ignore flag takes a comma-separated list of pairs of the form package:regex. For each package, the regex describes which functions to ignore within that package. The package may be omitted to have the regex apply to all packages. For example, you may wish to ignore common operations like Read and Write: errcheck -ignore '[rR]ead|[wW]rite' path/to/package or you may wish to ignore common functions like the print variants in fmt: errcheck -ignore 'fmt:[FS]?[Pp]rint*' path/to/package The -ignorepkg flag takes a comma-separated list of package import paths to ignore: errcheck -ignorepkg 'fmt,encoding/binary' path/to/package Note that this is equivalent to: errcheck -ignore 'fmt:.*,encoding/binary:.*' path/to/package If a regex is provided for a package pkg via -ignore, and pkg also appears in the list of packages passed to -ignorepkg, the latter takes precedence; that is, all functions within pkg will be ignored. Note that by default the fmt package is ignored entirely, unless a regex is specified for it. To disable this, specify a regex that matches nothing: errcheck -ignore 'fmt:a^' path/to/package The -ignoretests flag disables checking of _test.go files. It takes no arguments. The -ignoregenerated flag disables checking of generated source code. It takes no arguments. Exit Codes errcheck returns 1 if any problems were found in the checked files. It returns 2 if there were any other failures. Editor Integration Emacs go-errcheck.el integrates errcheck with Emacs by providing a go-errcheck command and customizable variables to automatically pass flags to errcheck. Vim vim-go can run errcheck via both its :GoErrCheck and :GoMetaLinter commands.
Read the full README on GitHub

What Hacker News says

33 sources
> Go compiler raise an error if a variable (error) goes unused It doesn't though. It's not a warning or error to not use the return value of a function that only returns an error, for instance (https://go.dev/play/p/se6-zHHVezH). There are static error checking tools you can use like https://github.com/kisielk/errcheck to work around this, but most people don't use them. I've run into a lack of Go error checking many times. Many times it's just the trivial case, where the compiler doesn't warn about not checking the result of an error-returning function. But often it'll be subtler, and the result of Go's API design. One example is its file writing API, which requires you to close the file and check its error to be correct. Many times people will just `defer file.Close()`, but that isn't good enough - you're ignoring the error there. Worse
Read the rest
still is e.g: writing to a file through a bufio.Writer. To be correct, you need to remember to flush the writer, check that error, then close the file and check that error. There's no type-level support to make sure you do that.
In I want off Mr. Golang’s Wild Ride (2020)
I'd be really happy with that! Building the functionality of errcheck[1] and ineffassign[2] into the compiler — or at the very least, into govet — would go a long way to allay my worries with Go. I think the reason they don't do this is that it's a slight (albeit a very tiny one) against Go's philosophy of errors being values, just like any other. While the `error` type is standard and used throughout Go source code, it still just has a simple three-line definition[3] and is not treated as a special case anywhere else; there is nothing stopping you from returning your own error type if you wish. A third-party linter could simply check for the `error` type specifically, but the first-party tools should not, and there's nothing like Rust's `#[must_use]` attribute that could be used instead. I respect Go's philosophy, but I feel like pragmat
Read the rest
In Trying Out Generics in Go
Staticcheck is inavluable, and I support it with words, actions, and money. Here are some additional tools that you might want to have in your module's tools.go: * github.com/kisielk/errcheck[1]: Find cases where you (accidentally?) ignore errors. * github.com/gordonklaus/ineffassign[2]: Find ineffectial assignments; sounds simple, almost unneeded, but in my practice it's actually one of the most effective analyses to find actual bugs. * mvdan.cc/unparam[3]: Find functions that always consume or return one value; great for refactorings. [1] https://github.com/kisielk/errcheck [2] https://github.com/gordonklaus/ineffassign [3] https://github.com/mvdan/unparam
In Improving Go code: An introduction to the static analysis tool Staticcheck

Showing the 15 most recent of 33 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.