我已经阅读了很多关于如何以及何时使用断言的文章(以及在StackOverflow上发布的其他几个类似问题),我对它们理解得很好.但是,我仍然不明白应该驱使我使用什么样的动机Debug.Assert而不是抛出一个普通的例外.我的意思是,在.NET中,对失败的断言的默认响应是"停止世界"并向用户显示一个消息框.虽然可以修改这种行为,但我觉得这样做非常烦人和多余,而我可以改为抛出一个合适的异常.这样,我可以在抛出异常之前轻松地将错误写入应用程序的日志,而且,我的应用程序不一定会冻结.
那么,为什么我应该使用Debug.Assert而不是普通的例外呢？将断言放在不应该出现的地方可能会导致各种"不需要的行为",所以在我看来,我真的没有通过使用断言而不是抛出异常来获得任何东西.你同意我的意见,还是我在这里遗漏了什么？
注意:我完全理解"在理论上"(调试与发布,使用模式等)之间的区别是什么,但正如我所看到的,我最好抛出异常而不是执行断言.因为如果在生产版本上发现了一个bug,我仍然希望"断言"失败(毕竟,"开销"非常小),所以我最好不要抛出异常.
编辑:我看到它的方式,如果断言失败,这意味着应用程序进入某种已损坏的意外状态.那么我为什么要继续执行呢？应用程序是否在调试版或发行版上运行并不重要.两者都是如此
我一直在为一些遗留的C++代码添加单元测试,并且我遇到了很多场景,其中函数内的断言在单元测试运行期间会被触发.我遇到的一个常见习语是带有指针参数的函数,如果参数为NULL则立即断言.
当我进行单元测试时,我可以通过禁用断言轻松解决这个问题.但我开始怀疑单元测试是否应该减轻对运行时断言的需求.这是正确的评估吗？单元测试是否应该通过在管道中更快地发生来替换运行时断言(即:错误是在失败的测试中捕获而不是在程序运行时).
另一方面,我不喜欢添加软代码失败(例如if (param == NULL) return false;).运行时断言至少可以在单元测试错过错误时更容易调试问题.
数学相关函数中错误处理的好习惯是什么？我正在建立一个专门的函数库(模块),我的主要目的是让调用这些函数的代码更容易调试 - 而不是制作一个闪亮的用户友好的错误处理工具.
下面是VBA中的一个简单示例,但我也有兴趣听取其他语言的说法.我不太确定我应该在哪里返回错误消息/状态/标志.作为额外的论点？
Function AddArrays(arr1, arr2)
Dim i As Long
Dim result As Variant
' Some error trapping code here, e.g.
' - Are input arrays of same size?
' - Are input arrays numeric? (can't add strings, objects...)
' - Etc.
' If no errors found, do the actual work...
ReDim result(LBound(arr1) To UBound(arr1))
For i = LBound(arr1) To UBound(arr1)
result(i) = arr1(i) + arr2(i)
Next i
AddArrays = result
End Function
或类似以下内容.该函数返回一个布尔"成功"标志(如下例所示,如果输入数组不是数字等,则返回False),或者某个其他类型的错误号/消息.
Function AddArrays(arr1, arr2, result) As …