Merge pull request #150 from lylex/feat_add_54

feat: add tip#54, refs #126

README.md

@@ -2,7 +2,7 @@
 <!-- ALL-CONTRIBUTORS-BADGE:START - Do not remove or modify this section -->
 [![All Contributors](https://img.shields.io/badge/all_contributors-18-orange.svg?style=flat-square)](#contributors-)
 <!-- ALL-CONTRIBUTORS-BADGE:END -->
-Go tips from [Phuong Le](https://twitter.com/func25). 
+Go tips from [Phuong Le](https://twitter.com/func25).
 
 翻译后的站点: [Go语言编程技巧](https://colobu.com/gotips/) (自动生成)
 
@@ -24,7 +24,7 @@ Go tips from [Phuong Le](https://twitter.com/func25).
 - 翻译请保持语句通顺，可以使用AI协助翻译，但是一定要避免生硬和机翻的感觉
 
 > **怎么提交Pull Request? **
-> 
+>
 > 如果大家以前没有提交过 Pull Request,可以探索下。
 > 首先点击项目右上角的 Fork 按钮，将项目 Fork 到自己的仓库。
 > 在github浏览你fork的项目，你会看到一个 "Create pull request" 按钮，点击它
@@ -107,7 +107,7 @@ Go tips from [Phuong Le](https://twitter.com/func25).
 | 51 | Avoid using init() |  richzw  |
 | 52 | Adjusting GOMAXPROCS for Containerized Env (Kubernetes, Docker, etc.) | baxiang |
 | 53 | Enums start from 1 for categorization and 0 for default cases | baxiang  |
-| 54 | 已认领 |           |
+| 54 | Only define errors (var Err = errors.New) when it's necessary for your client | lylex |
 | 55 | Prevent Struct Unkeyed Literals by Using an Empty Field  | cannian1 |
 | 56 | Simplify interfaces and only ask for what you really need  | cannian1 |
 | 57 | 已认领 |           |

src/054.md

@@ -0,0 +1,46 @@
+# Tip #54 仅在必要时为客户端定义error(var Err = errors.New)
+
+>  原始链接：[Golang Tips #54: Only define errors (var Err = errors.New) when it's necessary for your client](https://twitter.com/func25/status/1770437020617433240)
+>
+
+一个在很多代码库中都有的常见误区是，为**每个**逻辑错误定义一个error，每个error都有一个高度描述性的名称和说明。
+
+这种做法并不是总是必要的：
+
+![](./images/054/1.jpg)
+
+这通常出现在处理我们的业务逻辑的时候，开发人员想要**控制**每一个error，但是这是多余的。
+
+这里列举一些弊端（以上述例子为例）：
+
+- 这对于维护者是一个负担，他们必须记住或者查询每一个error的细节。
+- 除了你自己之外没人知道这是冗余的，甚至不久的将来你自己也会忘记。
+- 你的客户端可能不需要知道这些错误，因为前端早已限定了输入价格从高到低的区间了。
+
+只有当客户端绕过前端直接使用API时才会遇到这个error（这是一个我们不认可的行为）。
+
+这个原则不仅仅适用于客户端-服务端通信中，还适用于内部代码。
+
+例如，如果你无法向消息队列中投递一个消息时，别立即就创建一个ErrPublishMessage。
+很可能没有人会捕获这个error。
+
+**那么，这些场景下推荐的做法是什么呢？**
+
+当你的代码不需要客户端（不管是你的代码的一部分还是你写的库的外部用户）**根据error类型的不同而采取不同的行为**时，采取最简单的错误处理方法是最佳的：
+
+![](./images/054/2.png)
+
+或者使用fmt.Errorf，它能让你利用动态数据格式化出一个错误类型。
+
+这在需要包含上下文相关的信息时候特别有用。
+
+![](./images/054/3.png)
+
+当你的应用逻辑确实需要根据error类型的不同而要采取不同的行为时，例如：
+
+- 根据error类型决定是否重试一个操作。
+- 记录特定的error到日志中去。
+- 通知用户他们的资金即将耗尽，或者显示一个充值弹窗。
+- ...
+
+那么对于这些场景定义error变量才是完美的。

src/SUMMARY.md

@@ -46,6 +46,7 @@
 - [Tip #51 避免使用init()](./051.md)
 - [Tip #52 针对容器化环境（Kubernetes、Docker等）调整GOMAXPROCS](./052.md)
 - [Tip #53 枚举从1开始用于分类，从0用于默认情况](./053.md)
+- [Tip #54 仅在必要时为客户端定义error(var Err = errors.New)](./054.md)
 - [Tip #55 使用空字段防止结构体无键字面量](./055.md)
 - [Tip #56 简化接口并只要求你真正需要的东西](./056.md)
 - [Tip #58 将互斥锁放在保护的数据附近](./058.md)