做网站是什么会计科目,怎样更改WordPress的密码,dw网页设计作品 成品,wordpress如何改字体背景知识
在以前使用 VC 开发代码时#xff0c;微软提供了 ASSERT 和 VERIFY 宏#xff0c;其在调试环境下能比较方便的发现问题。我基于此设计了 CSTD(Code Self Test Development) 和 API_VERIFY , COM_VERIFY 等宏帮助我开发了几乎 0bug 的 C/C 代码.在使用 go 语言开发时…背景知识
在以前使用 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 its 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), msgopen 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), msginvalid 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 的方式控制似乎更合适. 之后慢慢学习和调整吧.
