2021-04-18

关于返回的错误信息的问题

接手别人的代码是比较痛苦的，在了解需求的情况下，还得了解代码实现的逻辑，否则两边对不上再写需求的话就更乱了，到最后，这块就没人敢碰了。估计哪家公司都有这样的“顽疾”，没人碰的了。上家公司是一线互联网公司了，这样的代码依然存在，某个模块的代码逻辑乱到令人发指的程度，一直说要重构，一直也没动，也不知道现在处理了没有。
这次不说重构，也不说接到别人代码该怎么办，说一个返回的错误信息。
我接到代码，熟悉了需求就开始调试一下代码，遇到几个关于返回错误信息的问题：

第一个就是，返回的错误信息不符
我通过curl发送一个交易请求，提示我“提交的交易签名错误”。于是找到提示这个错误提示的位置，看代码，可以说没有任何关系，再往下跟代码，其实在解析某个字段的时候出现的错误，某个必须的字段需要有的，但是请求中没有，于是出错了，最大的问题就是错误提示也不相符，增加调试时间。
再研究代码，发现这个错误，其实是用到了try，catch，捕获的，但是在catch里面返回的错误只是针对try的方法的，如：

try {
	print_a();
} 
catch(exception) {
	log("打印a出错")
}

其实 print_a 中还有很多逻辑，如：

print_a() {
	print_b();

	sign();

	print_c();

	drink();
}

任何一个出现错误，都被catch到，把问题归到 print_a 头上。这个也算是典型的需要重构的代码了，

第一就是一个方法实现了太大逻辑，一个方法一个功能的原则。
第二就是try的粒度太大了，这样反而try的意义也不大了。

第二就是，返回错误说明中英夹杂
这肯定需要统一的，要么都是中文，要么都是英文。来回跳这就显得很乱了。再说一下英文的信息，如果不能写出语法正确的句子，还是老实的写中文吧，起码中文再不济也能看出来说的什么意思，如果是语法错乱的英文句子，好了，不光和代码打交道，还有跟语法纠葛，这只能说明你的不专业，还徒增大家的理解难度。
第三就是，错误码不统一
同样的一个功能方法 f，在模块B实现的时候，提示ERROR_1，在模块B实现的时候，提示ERROR_2，写的很随意。

上边就是目前发现的几处关于返回错误值的问题，如果遇到这样的问题，千万抑制住起炉灶重造的想法，尽量的重构才是比较合适的做法。

关于工作上的问题都以伪代码表示。