1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
moby--moby/errors
Tonis Tiigi 4352da7803 Update daemon and docker core to use new content addressable storage
Add distribution package for managing pulls and pushes. This is based on
the old code in the graph package, with major changes to work with the
new image/layer model.

Add v1 migration code.

Update registry, api/*, and daemon packages to use the reference
package's types where applicable.

Update daemon package to use image/layer/tag stores instead of the graph
package

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
2015-11-24 09:40:25 -08:00
..
builder.go Move api/errors/ to errors/ 2015-09-17 11:54:14 -07:00
daemon.go Update daemon and docker core to use new content addressable storage 2015-11-24 09:40:25 -08:00
error.go Move api/errors/ to errors/ 2015-09-17 11:54:14 -07:00
image.go Adding error codes to image package 2015-09-23 17:03:37 +00:00
README.md Move api/errors/ to errors/ 2015-09-17 11:54:14 -07:00
server.go Return 404 for all network operations without network controller. 2015-10-19 14:40:18 -04:00

Docker 'errors' package

This package contains all of the error messages generated by the Docker engine that might be exposed via the Docker engine's REST API.

Each top-level engine package will have its own file in this directory so that there's a clear grouping of errors, instead of just one big file. The errors for each package are defined here instead of within their respective package structure so that Docker CLI code that may need to import these error definition files will not need to know or understand the engine's package/directory structure. In other words, all they should need to do is import .../docker/errors and they will automatically pick up all Docker engine defined errors. This also gives the engine developers the freedom to change the engine packaging structure (e.g. to CRUD packages) without worrying about breaking existing clients.

These errors are defined using the 'errcode' package. The errcode package allows for each error to be typed and include all information necessary to have further processing done on them if necessary. In particular, each error includes:

  • Value - a unique string (in all caps) associated with this error. Typically, this string is the same name as the variable name of the error (w/o the ErrorCode text) but in all caps.

  • Message - the human readable sentence that will be displayed for this error. It can contain '%s' substitutions that allows for the code generating the error to specify values that will be inserted in the string prior to being displayed to the end-user. The WithArgs() function can be used to specify the insertion strings. Note, the evaluation of the strings will be done at the time WithArgs() is called.

  • Description - additional human readable text to further explain the circumstances of the error situation.

  • HTTPStatusCode - when the error is returned back to a CLI, this value will be used to populate the HTTP status code. If not present the default value will be StatusInternalServerError, 500.

Not all errors generated within the engine's executable will be propagated back to the engine's API layer. For example, it is expected that errors generated by vendored code (under docker/vendor) and packaged code (under docker/pkg) will be converted into errors defined by this package.

When processing an errcode error, if you are looking for a particular error then you can do something like:

import derr "github.com/docker/docker/errors"

...

err := someFunc()
if err.ErrorCode() == derr.ErrorCodeNoSuchContainer {
	...
}