[GO]使用 CSTD(Code Self Test Development) 技术方式处理 error

背景知识

• 在以前使用 VC 开发代码时，微软提供了 ASSERT 和 VERIFY 宏，其在调试环境下能比较方便的发现问题。我基于此设计了 CSTD(Code Self Test Development) 和 API_VERIFY , COM_VERIFY 等宏帮助我开发了几乎 0bug 的 C/C++ 代码.
• 在使用 go 语言开发时, 发现系统也是采用返回 error 的方式进行错误的处理, 而且不像 java, python 等使用异常。因此被戏称为 一半时间写代码,一半时间处理错误。

Error 处理机制

• 对于错误机制的处理上，编码人员一般有两种做法：
  • 对部分的返回值不予判断(直接 _ = xxx )，认为程序的运行不会出现那些错误。虽然代码清爽了，但实际运行环境下当程序中出现函数调用失败时，由于没有及时处理，就留下了Bug隐患，直到N久之后才发作。于是程序员就需要花费大量的时间、精力去再现、确认、更改Bug；
  • 对所有函数调用的地方都进行判断和处理。于是代码中出现大量的if…else等分支判断，造成程序的编写、维护工作量大幅上升，但是很多代码估计永远都不会执行(谁能告诉我正常情况下 File.Close() 什么时候会失败，失败后又该做什么？)，而且往往在函数调用失败后，不判断具体的错误信息，只是简单的进行返回。没有日志的话，出现问题时很难定位。加日志的话，又到处都是日志。

CSTD(Code Self Test Development) 技术

• 通过编写特定的 VerifyXxx 函数(Go等) /宏(C++)，封装对指定函数的调用，自动检测函数的调用结果，在需要时打印日志、调用堆栈等，从而在发生问题时快速定位。
• 函数定义如下：

func Verify(err error) error {
	if err != nil {
		checkAndHandleError(err, err.Error(), verifyAction, _SKIP_LEVEL)
	}
	return err
}

func VerifyWithResult[T any](result T, err error) T {
	if err != nil {
		checkAndHandleError(err, err.Error(), verifyAction, _SKIP_LEVEL)
	}
	return result
}

func VerifyWithResultEx[T any](result T, err error) (T, error) {
	if err != nil {
		checkAndHandleError(err, err.Error(), verifyAction, _SKIP_LEVEL)
	}
	return result, err
}

func checkAndHandleError(err error, msg string, action CheckErrorAction, skip int) {
	if err != nil {
		fileName, lineNo, funName := flog.GetCallStackInfo(skip)
		msg := fmt.Sprintf("%s:%d (%s) FAIL(%s), msg=%s\n",
			fileName, lineNo, funName, reflect.TypeOf(err).String(), msg)
		switch action {
		case ACTION_LOG_ERROR:
			flog.Warnf(msg)
		case ACTION_FATAL_QUIT:
			panic(msg)
		}
	}
}

• 其中 checkAndHandleError 是一个自定义的辅助函数, 可以在 error 不为 nil 时打印错误信息, 从而快速定位错误位置. 实际上的业务代码中即可使用如下的简单调用房室 :

// example: open a file should exist(local config file),
// if it not exists, then it's code error or CI/CD error, not runtime error.
func TestVerify(t *testing.T) {
	file := VerifyWithResult(os.Open("should_exist_conf_file"))
	defer func() {
		//Notice: when try to close a nil(*os.File), error with "invalid argument"
		_ = Verify(file.Close())
	}()

	//file.Read(xxxx)
}

• 运行效果(可以看到代码中没有写日志的代码,但是程序发生问题时,能快速定位)

2024/01/29 21:31:54 [WARN] /path/to/go-library/debugutil/verify_test.go:13 (TestVerify) FAIL(*fs.PathError), msg=open should_exist_conf_file: The system cannot find the file specified.
2024/01/29 21:31:54 [WARN] /path/to/go-library/debugutil/verify_test.go:17 (func1) FAIL(*errors.errorString), msg=invalid argument

注意事项

• VerifyXxx 只是帮助发现和更改错误的辅助机制，绝对不是错误处理逻辑。在发生错误时，一定要根据 error 进行后续的错误处理。对于大多数正常情况下不会、不该出错的代码，可以简单使用 VerifyXxx 即可，但对于可能出错的代码(如 os.Open(用户提供的路径) )，则需要进行错误处理.
• 通常来说，合理使用 VerifyXxx 函数，能在很少投入的情况下（只需将原有代码中的“函数调用”换成“VerifyXxx(函数调用)”）即可发现和解决大部分的编码Bug，但如果结合敏捷开发中的TDD，将发挥更大威力。使用UT搭建自动化运行的框架并对功能进行测试，代码内部通过 VerifyXxx 进行测试。在分析、设计时仔细考虑一下，加上开发人员的责任心(实际上这才是实现0Bug程序的根本)，再通过这两个工具的结合，实现出 0 Bug的程序将不再是梦想。

完整的源码位置:

• https://gitee.com/fishjam/go-library/blob/main/debugutil/verify.go

补充信息

• 目前采用代码中写死的 verifyAction 变量进行异常发生时的逻辑控制，感觉可以通过 build tags 的方式控制似乎更合适. 之后慢慢学习和调整吧.