influxdb/errors_test.go

301 lines
7.2 KiB
Go
Raw Normal View History

package influxdb_test
2018-08-27 17:09:17 +00:00
import (
"encoding/json"
"errors"
"fmt"
"testing"
platform "github.com/influxdata/influxdb"
2018-08-27 17:09:17 +00:00
)
const EFailedToGetStorageHost = "failed to get the storage host"
func TestErrorMsg(t *testing.T) {
cases := []struct {
name string
err error
msg string
}{
{
name: "simple error",
err: &platform.Error{Code: platform.ENotFound},
2018-08-27 17:09:17 +00:00
msg: "<not found>",
},
{
refactor: http error serialization matches the new error schema (#15196) The http error schema has been changed to simplify the outward facing API. The `op` and `error` attributes have been dropped because they confused people. The `error` attribute will likely be readded in some form in the future, but only as additional context and will not be required or even suggested for the UI to use. Errors are now output differently both when they are serialized to JSON and when they are output as strings. The `op` is no longer used if it is present. It will only appear as an optional attribute if at all. The `message` attribute for an error is always output and it will be the prefix for any nested error. When this is serialized to JSON, the message is automatically flattened so a nested error such as: influxdb.Error{ Msg: errors.New("something bad happened"), Err: io.EOF, } This would be written to the message as: something bad happened: EOF This matches a developers expectations much more easily as most programmers assume that wrapping an error will act as a prefix for the inner error. This is flattened when written out to HTTP in order to make this logic immaterial to a frontend developer. The code is still present and plays an important role in categorizing the error type. On the other hand, the code will not be output as part of the message as it commonly plays a redundant and confusing role when humans read it. The human readable message usually gives more context and a message like with the code acting as a prefix is generally not desired. But, the code plays a very important role in helping to identify categories of errors and so it is very important as part of the return response.
2019-09-19 15:06:47 +00:00
name: "with message",
err: &platform.Error{
Code: platform.ENotFound,
refactor: http error serialization matches the new error schema (#15196) The http error schema has been changed to simplify the outward facing API. The `op` and `error` attributes have been dropped because they confused people. The `error` attribute will likely be readded in some form in the future, but only as additional context and will not be required or even suggested for the UI to use. Errors are now output differently both when they are serialized to JSON and when they are output as strings. The `op` is no longer used if it is present. It will only appear as an optional attribute if at all. The `message` attribute for an error is always output and it will be the prefix for any nested error. When this is serialized to JSON, the message is automatically flattened so a nested error such as: influxdb.Error{ Msg: errors.New("something bad happened"), Err: io.EOF, } This would be written to the message as: something bad happened: EOF This matches a developers expectations much more easily as most programmers assume that wrapping an error will act as a prefix for the inner error. This is flattened when written out to HTTP in order to make this logic immaterial to a frontend developer. The code is still present and plays an important role in categorizing the error type. On the other hand, the code will not be output as part of the message as it commonly plays a redundant and confusing role when humans read it. The human readable message usually gives more context and a message like with the code acting as a prefix is generally not desired. But, the code plays a very important role in helping to identify categories of errors and so it is very important as part of the return response.
2019-09-19 15:06:47 +00:00
Msg: "bucket not found",
2018-08-27 17:09:17 +00:00
},
refactor: http error serialization matches the new error schema (#15196) The http error schema has been changed to simplify the outward facing API. The `op` and `error` attributes have been dropped because they confused people. The `error` attribute will likely be readded in some form in the future, but only as additional context and will not be required or even suggested for the UI to use. Errors are now output differently both when they are serialized to JSON and when they are output as strings. The `op` is no longer used if it is present. It will only appear as an optional attribute if at all. The `message` attribute for an error is always output and it will be the prefix for any nested error. When this is serialized to JSON, the message is automatically flattened so a nested error such as: influxdb.Error{ Msg: errors.New("something bad happened"), Err: io.EOF, } This would be written to the message as: something bad happened: EOF This matches a developers expectations much more easily as most programmers assume that wrapping an error will act as a prefix for the inner error. This is flattened when written out to HTTP in order to make this logic immaterial to a frontend developer. The code is still present and plays an important role in categorizing the error type. On the other hand, the code will not be output as part of the message as it commonly plays a redundant and confusing role when humans read it. The human readable message usually gives more context and a message like with the code acting as a prefix is generally not desired. But, the code plays a very important role in helping to identify categories of errors and so it is very important as part of the return response.
2019-09-19 15:06:47 +00:00
msg: "bucket not found",
2018-08-27 17:09:17 +00:00
},
{
refactor: http error serialization matches the new error schema (#15196) The http error schema has been changed to simplify the outward facing API. The `op` and `error` attributes have been dropped because they confused people. The `error` attribute will likely be readded in some form in the future, but only as additional context and will not be required or even suggested for the UI to use. Errors are now output differently both when they are serialized to JSON and when they are output as strings. The `op` is no longer used if it is present. It will only appear as an optional attribute if at all. The `message` attribute for an error is always output and it will be the prefix for any nested error. When this is serialized to JSON, the message is automatically flattened so a nested error such as: influxdb.Error{ Msg: errors.New("something bad happened"), Err: io.EOF, } This would be written to the message as: something bad happened: EOF This matches a developers expectations much more easily as most programmers assume that wrapping an error will act as a prefix for the inner error. This is flattened when written out to HTTP in order to make this logic immaterial to a frontend developer. The code is still present and plays an important role in categorizing the error type. On the other hand, the code will not be output as part of the message as it commonly plays a redundant and confusing role when humans read it. The human readable message usually gives more context and a message like with the code acting as a prefix is generally not desired. But, the code plays a very important role in helping to identify categories of errors and so it is very important as part of the return response.
2019-09-19 15:06:47 +00:00
name: "with a third party error and no message",
err: &platform.Error{
refactor: http error serialization matches the new error schema (#15196) The http error schema has been changed to simplify the outward facing API. The `op` and `error` attributes have been dropped because they confused people. The `error` attribute will likely be readded in some form in the future, but only as additional context and will not be required or even suggested for the UI to use. Errors are now output differently both when they are serialized to JSON and when they are output as strings. The `op` is no longer used if it is present. It will only appear as an optional attribute if at all. The `message` attribute for an error is always output and it will be the prefix for any nested error. When this is serialized to JSON, the message is automatically flattened so a nested error such as: influxdb.Error{ Msg: errors.New("something bad happened"), Err: io.EOF, } This would be written to the message as: something bad happened: EOF This matches a developers expectations much more easily as most programmers assume that wrapping an error will act as a prefix for the inner error. This is flattened when written out to HTTP in order to make this logic immaterial to a frontend developer. The code is still present and plays an important role in categorizing the error type. On the other hand, the code will not be output as part of the message as it commonly plays a redundant and confusing role when humans read it. The human readable message usually gives more context and a message like with the code acting as a prefix is generally not desired. But, the code plays a very important role in helping to identify categories of errors and so it is very important as part of the return response.
2019-09-19 15:06:47 +00:00
Code: EFailedToGetStorageHost,
Err: errors.New("empty value"),
2018-08-27 17:09:17 +00:00
},
refactor: http error serialization matches the new error schema (#15196) The http error schema has been changed to simplify the outward facing API. The `op` and `error` attributes have been dropped because they confused people. The `error` attribute will likely be readded in some form in the future, but only as additional context and will not be required or even suggested for the UI to use. Errors are now output differently both when they are serialized to JSON and when they are output as strings. The `op` is no longer used if it is present. It will only appear as an optional attribute if at all. The `message` attribute for an error is always output and it will be the prefix for any nested error. When this is serialized to JSON, the message is automatically flattened so a nested error such as: influxdb.Error{ Msg: errors.New("something bad happened"), Err: io.EOF, } This would be written to the message as: something bad happened: EOF This matches a developers expectations much more easily as most programmers assume that wrapping an error will act as a prefix for the inner error. This is flattened when written out to HTTP in order to make this logic immaterial to a frontend developer. The code is still present and plays an important role in categorizing the error type. On the other hand, the code will not be output as part of the message as it commonly plays a redundant and confusing role when humans read it. The human readable message usually gives more context and a message like with the code acting as a prefix is generally not desired. But, the code plays a very important role in helping to identify categories of errors and so it is very important as part of the return response.
2019-09-19 15:06:47 +00:00
msg: "empty value",
2018-08-27 17:09:17 +00:00
},
{
refactor: http error serialization matches the new error schema (#15196) The http error schema has been changed to simplify the outward facing API. The `op` and `error` attributes have been dropped because they confused people. The `error` attribute will likely be readded in some form in the future, but only as additional context and will not be required or even suggested for the UI to use. Errors are now output differently both when they are serialized to JSON and when they are output as strings. The `op` is no longer used if it is present. It will only appear as an optional attribute if at all. The `message` attribute for an error is always output and it will be the prefix for any nested error. When this is serialized to JSON, the message is automatically flattened so a nested error such as: influxdb.Error{ Msg: errors.New("something bad happened"), Err: io.EOF, } This would be written to the message as: something bad happened: EOF This matches a developers expectations much more easily as most programmers assume that wrapping an error will act as a prefix for the inner error. This is flattened when written out to HTTP in order to make this logic immaterial to a frontend developer. The code is still present and plays an important role in categorizing the error type. On the other hand, the code will not be output as part of the message as it commonly plays a redundant and confusing role when humans read it. The human readable message usually gives more context and a message like with the code acting as a prefix is generally not desired. But, the code plays a very important role in helping to identify categories of errors and so it is very important as part of the return response.
2019-09-19 15:06:47 +00:00
name: "with a third party error and a message",
err: &platform.Error{
2018-08-27 17:09:17 +00:00
Code: EFailedToGetStorageHost,
refactor: http error serialization matches the new error schema (#15196) The http error schema has been changed to simplify the outward facing API. The `op` and `error` attributes have been dropped because they confused people. The `error` attribute will likely be readded in some form in the future, but only as additional context and will not be required or even suggested for the UI to use. Errors are now output differently both when they are serialized to JSON and when they are output as strings. The `op` is no longer used if it is present. It will only appear as an optional attribute if at all. The `message` attribute for an error is always output and it will be the prefix for any nested error. When this is serialized to JSON, the message is automatically flattened so a nested error such as: influxdb.Error{ Msg: errors.New("something bad happened"), Err: io.EOF, } This would be written to the message as: something bad happened: EOF This matches a developers expectations much more easily as most programmers assume that wrapping an error will act as a prefix for the inner error. This is flattened when written out to HTTP in order to make this logic immaterial to a frontend developer. The code is still present and plays an important role in categorizing the error type. On the other hand, the code will not be output as part of the message as it commonly plays a redundant and confusing role when humans read it. The human readable message usually gives more context and a message like with the code acting as a prefix is generally not desired. But, the code plays a very important role in helping to identify categories of errors and so it is very important as part of the return response.
2019-09-19 15:06:47 +00:00
Msg: "failed to get storage hosts",
2018-08-27 17:09:17 +00:00
Err: errors.New("empty value"),
},
refactor: http error serialization matches the new error schema (#15196) The http error schema has been changed to simplify the outward facing API. The `op` and `error` attributes have been dropped because they confused people. The `error` attribute will likely be readded in some form in the future, but only as additional context and will not be required or even suggested for the UI to use. Errors are now output differently both when they are serialized to JSON and when they are output as strings. The `op` is no longer used if it is present. It will only appear as an optional attribute if at all. The `message` attribute for an error is always output and it will be the prefix for any nested error. When this is serialized to JSON, the message is automatically flattened so a nested error such as: influxdb.Error{ Msg: errors.New("something bad happened"), Err: io.EOF, } This would be written to the message as: something bad happened: EOF This matches a developers expectations much more easily as most programmers assume that wrapping an error will act as a prefix for the inner error. This is flattened when written out to HTTP in order to make this logic immaterial to a frontend developer. The code is still present and plays an important role in categorizing the error type. On the other hand, the code will not be output as part of the message as it commonly plays a redundant and confusing role when humans read it. The human readable message usually gives more context and a message like with the code acting as a prefix is generally not desired. But, the code plays a very important role in helping to identify categories of errors and so it is very important as part of the return response.
2019-09-19 15:06:47 +00:00
msg: "failed to get storage hosts: empty value",
},
{
name: "with an internal error and no message",
err: &platform.Error{
Code: EFailedToGetStorageHost,
Err: &platform.Error{
Code: platform.EEmptyValue,
Msg: "empty value",
},
},
msg: "empty value",
2018-08-27 17:09:17 +00:00
},
{
refactor: http error serialization matches the new error schema (#15196) The http error schema has been changed to simplify the outward facing API. The `op` and `error` attributes have been dropped because they confused people. The `error` attribute will likely be readded in some form in the future, but only as additional context and will not be required or even suggested for the UI to use. Errors are now output differently both when they are serialized to JSON and when they are output as strings. The `op` is no longer used if it is present. It will only appear as an optional attribute if at all. The `message` attribute for an error is always output and it will be the prefix for any nested error. When this is serialized to JSON, the message is automatically flattened so a nested error such as: influxdb.Error{ Msg: errors.New("something bad happened"), Err: io.EOF, } This would be written to the message as: something bad happened: EOF This matches a developers expectations much more easily as most programmers assume that wrapping an error will act as a prefix for the inner error. This is flattened when written out to HTTP in order to make this logic immaterial to a frontend developer. The code is still present and plays an important role in categorizing the error type. On the other hand, the code will not be output as part of the message as it commonly plays a redundant and confusing role when humans read it. The human readable message usually gives more context and a message like with the code acting as a prefix is generally not desired. But, the code plays a very important role in helping to identify categories of errors and so it is very important as part of the return response.
2019-09-19 15:06:47 +00:00
name: "with an internal error and a message",
err: &platform.Error{
2018-08-27 17:09:17 +00:00
Code: EFailedToGetStorageHost,
refactor: http error serialization matches the new error schema (#15196) The http error schema has been changed to simplify the outward facing API. The `op` and `error` attributes have been dropped because they confused people. The `error` attribute will likely be readded in some form in the future, but only as additional context and will not be required or even suggested for the UI to use. Errors are now output differently both when they are serialized to JSON and when they are output as strings. The `op` is no longer used if it is present. It will only appear as an optional attribute if at all. The `message` attribute for an error is always output and it will be the prefix for any nested error. When this is serialized to JSON, the message is automatically flattened so a nested error such as: influxdb.Error{ Msg: errors.New("something bad happened"), Err: io.EOF, } This would be written to the message as: something bad happened: EOF This matches a developers expectations much more easily as most programmers assume that wrapping an error will act as a prefix for the inner error. This is flattened when written out to HTTP in order to make this logic immaterial to a frontend developer. The code is still present and plays an important role in categorizing the error type. On the other hand, the code will not be output as part of the message as it commonly plays a redundant and confusing role when humans read it. The human readable message usually gives more context and a message like with the code acting as a prefix is generally not desired. But, the code plays a very important role in helping to identify categories of errors and so it is very important as part of the return response.
2019-09-19 15:06:47 +00:00
Msg: "failed to get storage hosts",
Err: &platform.Error{
Code: platform.EEmptyValue,
Msg: "empty value",
},
2018-08-27 17:09:17 +00:00
},
refactor: http error serialization matches the new error schema (#15196) The http error schema has been changed to simplify the outward facing API. The `op` and `error` attributes have been dropped because they confused people. The `error` attribute will likely be readded in some form in the future, but only as additional context and will not be required or even suggested for the UI to use. Errors are now output differently both when they are serialized to JSON and when they are output as strings. The `op` is no longer used if it is present. It will only appear as an optional attribute if at all. The `message` attribute for an error is always output and it will be the prefix for any nested error. When this is serialized to JSON, the message is automatically flattened so a nested error such as: influxdb.Error{ Msg: errors.New("something bad happened"), Err: io.EOF, } This would be written to the message as: something bad happened: EOF This matches a developers expectations much more easily as most programmers assume that wrapping an error will act as a prefix for the inner error. This is flattened when written out to HTTP in order to make this logic immaterial to a frontend developer. The code is still present and plays an important role in categorizing the error type. On the other hand, the code will not be output as part of the message as it commonly plays a redundant and confusing role when humans read it. The human readable message usually gives more context and a message like with the code acting as a prefix is generally not desired. But, the code plays a very important role in helping to identify categories of errors and so it is very important as part of the return response.
2019-09-19 15:06:47 +00:00
msg: "failed to get storage hosts: empty value",
2018-08-27 17:09:17 +00:00
},
}
for _, c := range cases {
if c.msg != c.err.Error() {
t.Errorf("%s failed, want %s, got %s", c.name, c.msg, c.err.Error())
2018-08-27 17:09:17 +00:00
}
}
}
func TestErrorMessage(t *testing.T) {
cases := []struct {
name string
err error
want string
}{
{
name: "nil error",
},
{
name: "nil error of type *platform.Error",
err: (*platform.Error)(nil),
},
2018-08-27 17:09:17 +00:00
{
name: "simple error",
err: &platform.Error{Msg: "simple error"},
2018-08-27 17:09:17 +00:00
want: "simple error",
},
{
2019-04-17 20:30:22 +00:00
name: "embedded error",
err: &platform.Error{Err: &platform.Error{Msg: "embedded error"}},
want: "embedded error",
2018-08-27 17:09:17 +00:00
},
{
name: "default error",
err: errors.New("s"),
want: "An internal error has occurred.",
},
}
for _, c := range cases {
if result := platform.ErrorMessage(c.err); c.want != result {
t.Errorf("%s failed, want %s, got %s", c.name, c.want, result)
2018-08-27 17:09:17 +00:00
}
}
}
2018-11-07 18:55:52 +00:00
func TestErrorOp(t *testing.T) {
cases := []struct {
name string
err error
want string
}{
{
name: "nil error",
},
{
name: "nil error of type *platform.Error",
err: (*platform.Error)(nil),
},
2018-11-07 18:55:52 +00:00
{
name: "simple error",
err: &platform.Error{Op: "op1"},
want: "op1",
},
{
2019-04-17 20:30:22 +00:00
name: "embedded error",
2018-11-07 18:55:52 +00:00
err: &platform.Error{Op: "op1", Err: &platform.Error{Code: platform.EInvalid}},
want: "op1",
},
2018-11-07 18:55:52 +00:00
{
2019-04-17 20:30:22 +00:00
name: "embedded error without op in root level",
2018-11-07 18:55:52 +00:00
err: &platform.Error{Err: &platform.Error{Code: platform.EInvalid, Op: "op2"}},
want: "op2",
},
2018-11-07 18:55:52 +00:00
{
name: "default error",
err: errors.New("s"),
want: "",
},
}
for _, c := range cases {
if result := platform.ErrorOp(c.err); c.want != result {
t.Errorf("%s failed, want %s, got %s", c.name, c.want, result)
2018-11-07 18:55:52 +00:00
}
}
}
2018-08-27 17:09:17 +00:00
func TestErrorCode(t *testing.T) {
cases := []struct {
name string
err error
want string
}{
{
name: "nil error",
},
{
name: "nil error of type *platform.Error",
err: (*platform.Error)(nil),
},
2018-08-27 17:09:17 +00:00
{
name: "simple error",
err: &platform.Error{Code: platform.ENotFound},
want: platform.ENotFound,
2018-08-27 17:09:17 +00:00
},
{
2019-04-17 20:30:22 +00:00
name: "embedded error",
err: &platform.Error{Code: platform.ENotFound, Err: &platform.Error{Code: platform.EInvalid}},
want: platform.ENotFound,
2018-08-27 17:09:17 +00:00
},
2018-11-07 18:55:52 +00:00
{
2019-04-17 20:30:22 +00:00
name: "embedded error with root level code",
2018-11-07 18:55:52 +00:00
err: &platform.Error{Err: &platform.Error{Code: platform.EInvalid}},
want: platform.EInvalid,
},
2018-08-27 17:09:17 +00:00
{
name: "default error",
err: errors.New("s"),
want: platform.EInternal,
2018-08-27 17:09:17 +00:00
},
}
for _, c := range cases {
if result := platform.ErrorCode(c.err); c.want != result {
t.Errorf("%s failed, want %s, got %s", c.name, c.want, result)
2018-08-27 17:09:17 +00:00
}
}
}
func TestJSON(t *testing.T) {
cases := []struct {
name string
err *platform.Error
encoded string
2018-08-27 17:09:17 +00:00
}{
{
name: "simple error",
err: &platform.Error{Code: platform.ENotFound},
encoded: `{"code":"not found"}`,
2018-08-27 17:09:17 +00:00
},
{
name: "with op",
err: &platform.Error{
Code: platform.ENotFound,
2018-08-27 17:09:17 +00:00
Op: "bolt.FindAuthorizationByID",
},
encoded: `{"code":"not found","op":"bolt.FindAuthorizationByID"}`,
2018-08-27 17:09:17 +00:00
},
{
name: "with op and value",
err: &platform.Error{
Code: platform.ENotFound,
Op: "bolt/FindAuthorizationByID",
2018-08-27 17:09:17 +00:00
Msg: fmt.Sprintf("with ID %d", 323),
},
encoded: `{"code":"not found","message":"with ID 323","op":"bolt/FindAuthorizationByID"}`,
2018-08-27 17:09:17 +00:00
},
{
name: "with a third party error",
err: &platform.Error{
2018-08-27 17:09:17 +00:00
Code: EFailedToGetStorageHost,
Op: "cmd/fluxd.injectDeps",
Err: errors.New("empty value"),
},
encoded: `{"code":"failed to get the storage host","op":"cmd/fluxd.injectDeps","error":"empty value"}`,
2018-08-27 17:09:17 +00:00
},
{
name: "with a internal error",
err: &platform.Error{
2018-08-27 17:09:17 +00:00
Code: EFailedToGetStorageHost,
Op: "cmd/fluxd.injectDeps",
Err: &platform.Error{Code: platform.EEmptyValue, Op: "cmd/fluxd.getStrList"},
2018-08-27 17:09:17 +00:00
},
encoded: `{"code":"failed to get the storage host","op":"cmd/fluxd.injectDeps","error":{"code":"empty value","op":"cmd/fluxd.getStrList"}}`,
},
{
name: "with a deep internal error",
err: &platform.Error{
Code: EFailedToGetStorageHost,
Op: "cmd/fluxd.injectDeps",
Err: &platform.Error{
Code: platform.EInvalid,
Op: "cmd/fluxd.getStrList",
Err: &platform.Error{
Code: platform.EEmptyValue,
Err: errors.New("an err"),
},
},
},
encoded: `{"code":"failed to get the storage host","op":"cmd/fluxd.injectDeps","error":{"code":"invalid","op":"cmd/fluxd.getStrList","error":{"code":"empty value","error":"an err"}}}`,
2018-08-27 17:09:17 +00:00
},
}
for _, c := range cases {
result, err := json.Marshal(c.err)
// encode testing
if err != nil {
t.Errorf("%s encode failed, want err: %v, should be nil", c.name, err)
2018-08-27 17:09:17 +00:00
}
if string(result) != c.encoded {
t.Errorf("%s encode failed, want result: %s, got %s", c.name, c.encoded, string(result))
}
2018-08-27 17:09:17 +00:00
// decode testing
got := new(platform.Error)
err = json.Unmarshal(result, got)
2018-08-27 17:09:17 +00:00
if err != nil {
t.Errorf("%s decode failed, want err: %v, should be nil", c.name, err)
2018-08-27 17:09:17 +00:00
}
decodeEqual(t, c.err, got, "decode: "+c.name)
}
}
func decodeEqual(t *testing.T, want, result *platform.Error, caseName string) {
2018-08-27 17:09:17 +00:00
if want.Code != result.Code {
t.Errorf("%s code failed, want %s, got %s", caseName, want.Code, result.Code)
2018-08-27 17:09:17 +00:00
}
if want.Op != result.Op {
t.Errorf("%s op failed, want %s, got %s", caseName, want.Op, result.Op)
2018-08-27 17:09:17 +00:00
}
if want.Msg != result.Msg {
t.Errorf("%s msg failed, want %s, got %s", caseName, want.Msg, result.Msg)
2018-08-27 17:09:17 +00:00
}
if want.Err != nil {
if _, ok := want.Err.(*platform.Error); ok {
decodeEqual(t, want.Err.(*platform.Error), result.Err.(*platform.Error), caseName)
2018-08-27 17:09:17 +00:00
} else {
if want.Err.Error() != result.Err.Error() {
t.Errorf("%s Err failed, want %s, got %s", caseName, want.Err.Error(), result.Err.Error())
2018-08-27 17:09:17 +00:00
}
}
}
}