runc/error.go

38 lines
664 B
Go
Raw Normal View History

Add rich errors to the API Add a rich Error type to the libcontainer package and use it in the API so that callers can: * Check for a specific error without depending on an error string, * Obtain the stack trace of the function or method which detected the error. The Error type provides a typed error code and a stack trace. The error code identifies the error and enables the caller to test for it without being sensitive to changes in the error text. The stack trace identifies the point at which the error was detected. The combination of error code and stack trace will enable errors to be diagnosed much more easily and with less guesswork than when raw string-based errors are used. The Error type conforms to the error interface and its Error method prints a short error message. The Detail method provides a verbose error message including the stack trace. Notes: 1. There is an unfortunate precedent in the Go standard library which uses variables to define errors. Checking for a specific error involves a string comparison and assumes the corresponding variable has not been updated. It is more robust and efficient to identify errors with integer-based types and associated constants, although errors should still include a string description for ease of use by humans. 2. It is not feasible to assign distinct types to Factory and Container error codes because common errors such as SystemError cannot be declared in two places and the names of the error codes then need to be decorated. This is less readable. Signed-off-by: Steve Powell <spowell@pivotal.io>
2014-09-04 07:03:41 +08:00
package libcontainer
// API error code type.
type ErrorCode int
// API error codes.
const (
// Factory errors
IdInUse ErrorCode = iota
InvalidIdFormat
// TODO: add Load errors
// Container errors
ContainerDestroyed
ContainerPaused
// Common errors
ConfigInvalid
Add rich errors to the API Add a rich Error type to the libcontainer package and use it in the API so that callers can: * Check for a specific error without depending on an error string, * Obtain the stack trace of the function or method which detected the error. The Error type provides a typed error code and a stack trace. The error code identifies the error and enables the caller to test for it without being sensitive to changes in the error text. The stack trace identifies the point at which the error was detected. The combination of error code and stack trace will enable errors to be diagnosed much more easily and with less guesswork than when raw string-based errors are used. The Error type conforms to the error interface and its Error method prints a short error message. The Detail method provides a verbose error message including the stack trace. Notes: 1. There is an unfortunate precedent in the Go standard library which uses variables to define errors. Checking for a specific error involves a string comparison and assumes the corresponding variable has not been updated. It is more robust and efficient to identify errors with integer-based types and associated constants, although errors should still include a string description for ease of use by humans. 2. It is not feasible to assign distinct types to Factory and Container error codes because common errors such as SystemError cannot be declared in two places and the names of the error codes then need to be decorated. This is less readable. Signed-off-by: Steve Powell <spowell@pivotal.io>
2014-09-04 07:03:41 +08:00
SystemError
)
// API Error type.
type Error interface {
error
// Returns the stack trace, if any, which identifies the
// point at which the error occurred.
Stack() []byte
// Returns a verbose string including the error message
// and a representation of the stack trace suitable for
// printing.
Detail() string
// Returns the error code for this error.
Code() ErrorCode
}