runc/error.go

63 lines
1.1 KiB
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
import "io"
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
// API error code type.
type ErrorCode int
// API error codes.
const (
// Factory errors
IdInUse ErrorCode = iota
InvalidIdFormat
// Container errors
ContainerNotExists
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
ContainerPaused
ContainerNotStopped
ContainerNotRunning
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
// Process errors
ProcessNotExecuted
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
// 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
)
func (c ErrorCode) String() string {
switch c {
case IdInUse:
return "Id already in use"
case InvalidIdFormat:
return "Invalid format"
case ContainerPaused:
return "Container paused"
case ConfigInvalid:
return "Invalid configuration"
case SystemError:
return "System error"
case ContainerNotExists:
return "Container does not exist"
case ContainerNotStopped:
return "Container is not stopped"
case ContainerNotRunning:
return "Container is not running"
default:
return "Unknown error"
}
}
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
// API Error type.
type Error interface {
error
// Returns a verbose string including the error message
// and a representation of the stack trace suitable for
// printing.
Detail(w io.Writer) error
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
// Returns the error code for this error.
Code() ErrorCode
}