All Projects → breml → errchkjson

breml / errchkjson

Licence: MIT license
Go linter that checks types that are json encoded - reports unsupported types and unnecessary error checks

Programming Languages

go
31211 projects - #10 most used programming language

Projects that are alternatives of or similar to errchkjson

flake8-putty
Flake8 plugin to control reporting per file and line
Stars: ✭ 38 (+31.03%)
Mutual labels:  linter
nano-staged
Tiny tool to run commands for modified, staged, and committed files in a GIT repository.
Stars: ✭ 347 (+1096.55%)
Mutual labels:  linter
healthier
🧘‍♀️ Healthier is an opinionated style agnostic code linter – a friendly companion to Prettier
Stars: ✭ 78 (+168.97%)
Mutual labels:  linter
f2e-spec
Alibaba Front-end Coding Guidelines and Relevant Tools
Stars: ✭ 548 (+1789.66%)
Mutual labels:  linter
vscode-linter
Extension for code linting, all in one package. New linters can be easily added through an extension framework.
Stars: ✭ 47 (+62.07%)
Mutual labels:  linter
nimfmt
Nim code formatter / linter / style checker
Stars: ✭ 75 (+158.62%)
Mutual labels:  linter
tryceratops
A linter to prevent exception handling antipatterns in Python (limited only for those who like dinosaurs).
Stars: ✭ 381 (+1213.79%)
Mutual labels:  linter
codeclimate-apexmetrics
ApexMetrics - Code Climate engine for Salesforce [DISCONTINUED use CC PMD instead)
Stars: ✭ 46 (+58.62%)
Mutual labels:  linter
yamburger
YAML syntax got you down? That's a YAMBURGER!
Stars: ✭ 32 (+10.34%)
Mutual labels:  linter
flexlint
A flexible linter with rules defined by regular expression
Stars: ✭ 19 (-34.48%)
Mutual labels:  linter
vue-cli-template-library
Template for developing open-source vue.js libraries with Rollup + Jest + Babel + Storybook + TravisCI + SemanticRelease
Stars: ✭ 61 (+110.34%)
Mutual labels:  linter
repolint
Tool to check github user/organization repositories for some simple and common issues.
Stars: ✭ 19 (-34.48%)
Mutual labels:  linter
linter-terraform-syntax
terraform validate linter and formatter for atom
Stars: ✭ 19 (-34.48%)
Mutual labels:  linter
elm-lint
elm-lint lints Elm source code, to add additional guarantees to your project.
Stars: ✭ 27 (-6.9%)
Mutual labels:  linter
retext-assuming
Check for unhelpful ‘assuming’ phrases such as ‘just’, ‘simply’ or ‘obviously’ with retext
Stars: ✭ 15 (-48.28%)
Mutual labels:  linter
node-lintspaces
A validator for checking different kinds of whitespaces in your files.
Stars: ✭ 31 (+6.9%)
Mutual labels:  linter
prlint
GitHub App for linting pull request meta data
Stars: ✭ 122 (+320.69%)
Mutual labels:  linter
sqlclosecheck
Linter that confirms that DB rows and stats are closed properly.
Stars: ✭ 21 (-27.59%)
Mutual labels:  linter
actionlint
Static checker for GitHub Actions workflow files
Stars: ✭ 1,385 (+4675.86%)
Mutual labels:  linter
flake8-spellcheck
❄️ Spellcheck variables, classnames, comments, docstrings etc
Stars: ✭ 71 (+144.83%)
Mutual labels:  linter

errchkjson

Test Status Go Report Card License

Checks types passed to the json encoding functions. Reports unsupported types and reports occurrences where the check for the returned error can be omitted.

Consider this http.Handler:

func JSONHelloWorld(w http.ResponseWriter, r *http.Request) {
	response := struct {
		Message string
		Code    int
	}{
		Message: "Hello World",
		Code:    200,
	}

	body, err := json.Marshal(response)
	if err != nil {
		panic(err) // unreachable, because json encoding of a struct with just a string and an int will never return an error.
	}

	w.Write(body)
}

Because the panic is not possible to happen, one might refactor the code like this:

func JSONHelloWorld(w http.ResponseWriter, r *http.Request) {
	response := struct {
		Message string
		Code    int
	}{
		Message: "Hello World",
		Code:    200,
	}

	body, _ := json.Marshal(response)

	w.Write(body)
}

This is ok, as long as the struct is not altered in such a way, that could potentially lead to json.Marshal returning an error.

errchkjson allows you to lint your code such that the above error returned from json.Marshal can be omitted while still staying safe, because as soon as an unsafe type is added to the response type, the linter will warn you.

Installation

Download errchkjson from the releases or get the latest version from source with:

go get github.com/breml/errchkjson/cmd/errchkjson

Usage

Shell

Check everything:

errchkjson ./...

errchkjson also recognizes the following command-line options:

The -omit-safe flag disables checking for safe returns of errors from json.Marshal

Types

Safe

The following types are safe to use with json encoding functions, that is, the encoding to JSON can not fail:

Safe basic types:

  • bool
  • int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64, uintptr
  • string
  • Pointer type of the above listed basic types

Composed types (struct, map, slice, array) are safe, if the type of the value is safe. For structs, only exported fields are relevant. For maps, the key needs to be either an integer type or a string.

Unsafe

The following types are unsafe to use with json encoding functions, that is, the encoding to JSON can fail (return an error):

Unsafe basic types:

  • float32, float64
  • interface{}
  • Pointer type of the above listed basic types

Any composed types (struct, map, slice, array) containing an unsafe basic type.

If a type implements the json.Marshaler or encoding.TextMarshaler interface (e.g. json.Number).

Forbidden

Forbidden basic types:

  • complex64, complex128
  • chan
  • func
  • unsafe.Pointer

Any composed types (struct, map, slice, array) containing a forbidden basic type. Any map using a key with a forbidden type (bool, float32, float64, struct).

Accepted edge case

For encoding/json.MarshalIndent, there is a (pathological) edge case, where this function could return an error for an otherwise safe argument, if the argument has a nesting depth larger than 10000 (as of Go 1.18).

Bugs found during development

During the development of errcheckjson, the following issues in package encoding/json of the Go standard library have been found and PR have been merged:

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].