do not define dynamic errors, use wrapped static errors instead: "fmt.Errorf("docker image is not set")" (err113)

[CarlJi]

这个警告提醒你不要定义动态错误，而是应该使用静态错误并通过错误包装来处理错误。

背景

在 Go 语言中，我们可以通过 fmt.Errorf 动态创建错误，尤其是带有格式化字符串的错误信息。然而，对于一些固定的错误信息，不建议每次都动态生成新的错误对象。相反，应该使用预定义的、可复用的静态错误（通常是一个包级别的 var 错误变量），并在需要时对错误进行包装或附加上下文。

原因

1. 复用和比较：在 Go 中，通过 errors.Is 或直接比较错误值，可以轻松判断错误的类型。如果每次都通过 fmt.Errorf 动态生成错误对象，那么这些错误对象是不同的，无法直接进行比较。

2. 性能：静态错误的内存分配只会发生一次，而动态生成的错误会在每次生成时分配新的内存，增加不必要的开销。

3. 可读性：使用静态错误可以让代码更加简洁和可维护，因为常见的错误可以在包级别定义并复用。

示例

错误的做法（动态错误）

// 动态生成错误信息
err := fmt.Errorf("docker image is not set")

这种方式会每次生成一个新的错误对象，导致错误无法复用和比较。

正确的做法（使用静态错误）

你可以定义一个静态的错误变量，然后在需要时用它来表示特定类型的错误：

// 定义一个静态错误
var ErrDockerImageNotSet = errors.New("docker image is not set")

// 使用静态错误
if someCondition {
    return ErrDockerImageNotSet
}

这样做有几个好处：

1. 复用：ErrDockerImageNotSet 是静态定义的，可以在不同的地方复用。

2. 比较：可以通过 errors.Is 或直接比较来判断错误类型：

   if errors.Is(err, ErrDockerImageNotSet) {
       // 处理 docker image 未设置的错误
   }

包装错误以增加上下文信息

如果你想使用静态错误并且还想在错误中附加一些上下文信息，可以使用 fmt.Errorf 和 "%w" 语法来包装静态错误，而不是动态生成新的错误：

var ErrDockerImageNotSet = errors.New("docker image is not set")

// 包装错误并添加上下文信息
return fmt.Errorf("failed to start container: %w", ErrDockerImageNotSet)

在这个例子中，我们保留了静态错误 ErrDockerImageNotSet，并通过 %w 包装错误，保持了错误可比较的特性，同时附加了上下文信息 "failed to start container"。

总结

• fmt.Errorf("docker image is not set") 是一种动态错误的创建方式，每次都会生成新的错误对象。
• 静态错误是通过 errors.New 或 var 定义的全局错误变量，便于复用和比较。
• 在需要提供上下文信息时，可以用 fmt.Errorf 和 "%w" 包装静态错误，而不是直接创建新的动态错误。

因此，err113 的意思是：不要使用动态生成的错误，而应定义静态错误并在需要时进行包装。

[CarlJi]

如果我这个错误，只出现一次，为此还单独定义变量，会不会太麻烦了？

[CarlJi]

确实，为只在代码中出现一次的错误定义一个全局变量，可能看起来有些繁琐，尤其是如果你的项目规模较小或者你觉得这个错误不会在其他地方复用。

但是，建议你权衡以下几点：

1. 代码可维护性

虽然某个错误当前只出现一次，但未来代码可能会发生变化，或者你可能会在其他地方需要复用这个错误。提早定义静态错误变量可以提升代码的可维护性和一致性。

例如，今天你只在一个地方用到这个错误，未来这个错误可能会在多个地方复用。预定义一个静态错误变量可以使未来的修改更加方便，避免到时候再去修改多个地方。

2. 错误类型一致性

使用静态错误变量的另一个好处是，你可以通过 errors.Is 或 errors.As 来进行错误类型的判断。如果你在未来的代码中需要判断这个错误的类型，静态错误变量可以让你更轻松地进行比较。此外，保持错误的一致性有助于排查和调试。

if errors.Is(err, ErrDockerImageNotSet) {
    // 处理 docker image 未设置的错误
}

如果你使用动态生成的错误（如 fmt.Errorf("docker image is not set")），你将无法通过 errors.Is 进行一致性判断。

3. 对性能的影响

虽然在大多数情况下，性能差异可能并不明显，但静态错误的内存分配只会发生一次，而动态生成的错误对象会在每次调用时重新分配内存。而且，在高并发场景下，频繁创建新的错误对象可能会对性能产生一定影响。

4. 简洁性和合理性

如果你觉得为一个只使用一次的错误定义变量确实过于麻烦，并且你确定这个错误不会在未来复用，你可以在这种场景下适当地忽略静态错误的建议。代码的简洁性也是一个重要的考虑因素。

例如，如果你在一个小的函数中生成错误，并且不打算复用或进行类型判断，使用 fmt.Errorf 也是合理的：

return fmt.Errorf("docker image is not set")

5. 折中的做法

如果你不喜欢为每个错误都定义一个变量，还有另一种折中的方法：你可以在某些情况下使用包级别常量来定义一些常见的错误信息。对于非常简单、明确的错误，可以通过这种方式简化代码。

例如，如果你有多个地方可能会出现类似的错误，你可以定义一个通用的静态错误：

var ErrInvalidOperation = errors.New("invalid operation")

然后在多个地方复用这个错误，而不是为每个错误都定义新的变量。

总结

• 全局静态错误变量 提供了复用性、一致性和性能优化，但对于只出现一次或不需要进行类型判断的错误，确实会显得有些繁琐。
• 如果你确定某个错误不会被复用，在少量场景下继续使用 fmt.Errorf 也是可以接受的，尤其是为了代码的简洁性。
• 权衡点是：如果你认为未来可能会复用这个错误或进行错误类型判断，最好还是定义一个静态错误变量；否则，使用动态错误生成也是合理的选择。

因此，虽然静态分析工具建议使用静态错误，但你可以根据实际情况选择最适合的实现方式。