大多数时候我会使用异常来检查代码中的条件,我想知道什么时候使用断言是合适的时间？
例如,
Group group=null;
try{
group = service().getGroup("abc");
}catch(Exception e){
//I dont log error because I know whenever error occur mean group not found
}
if(group !=null)
{
//do something
}
你能指出断言如何适应这里吗？我应该使用断言吗？
看起来我从不在生产代码中使用断言,只在单元测试中看到断言.我知道在大多数情况下,我可以使用异常来执行上面的检查,但我想知道"专业"的适当方式.
Java异常处理和使用assert条件之间有什么区别？
众所周知,Assert有两种类型.但什么时候应该使用assert关键字？
之前已经在这里询问过异常vs assert:使用断言或异常进行合同设计？,Assertion VS Runtime异常,C++错误代码vs ASSERTS vs Exceptions选择选择:(,通过使用断言或例外的合同设计？等等)(*)还有书籍,如Herb Sutter的编码标准,谈论这个.共识似乎是这样的:
对于内部错误使用断言,因为模块的用户和开发人员是同一个人/团队.对其他一切使用例外.(**)
除了一件事,这条规则对我来说很有意义.我是一名科学家,使用C++进行科学模拟.在我的特定上下文中,这意味着我是我的大部分代码的唯一用户.如果我应用此规则,这意味着我永远不必使用例外？我想不会,例如,仍然存在I/O错误或内存分配问题,其中仍然需要例外.但除了我的程序与"外部世界"的那些交互之外,还有其他情况我应该使用异常吗？
根据我的经验,许多优秀的编程实践对我来说非常有用,尽管这些实践主要是为大型复杂系统或大型团队设计的,而我的程序主要是小型科学模拟,主要由我自己编写.因此这个问题.什么样的例外使用做法适用于我的背景？或者我应该只使用断言(以及I/O的异常,内存分配以及与"外部世界"的其他交互)？
(*)我希望在阅读完整的问题后,您同意这不是重复的.一般来说,异常vs断言的主题已经处理过了,但是,正如我在这里解释的那样,我不认为这些问题中的任何一个都能解决我的特殊情况.
(**)我用自己的话写下这个,试着恢复我读过的东西.如果您觉得它不能反映大多数人的共识,请随意批评这一陈述.