TER*_*ytE 6 c++ defensive-programming
可能重复:
防御性编程
今天早上我们就防御性节目的主题进行了很好的讨论.我们进行了代码审查,其中传入指针并且未检查它是否有效.
有些人认为只需要检查空指针.我质疑它是否可以在更高级别进行检查,而不是通过它传递的每个方法,并且如果该点另一端的对象不满足某些要求,则检查null是非常有限的检查.
我理解并同意检查null总比没有好,但我觉得只检查null会提供错误的安全感,因为它的范围有限.如果要确保指针可用,请检查多于null.
你对这个问题有什么经验？如何在代码中为传递给从属方法的参数编写防御措施？
mch*_*mch 16
在Code Complete 2中,在关于错误处理的章节中,我了解了路障的概念.本质上,路障是严格验证进入其中的所有输入的代码.街垒内的代码可以假设已经处理了任何无效输入,并且接收的输入是好的.在街垒内,代码只需要担心街垒内其他代码传递给它的无效数据.断言条件和明智的单元测试可以增加您对阻塞代码的信心.通过这种方式,你可以在街垒上进行非常防御性的编程,但在街垒内部却不那么严重.考虑它的另一种方法是在路障中,你总是正确地处理错误,而在路障中你只是在调试版本中断言条件.
就使用原始指针而言,通常你能做的最好就是断言指针不是null.如果您知道该内存中应该是什么,那么您可以确保内容在某种程度上是一致的.这就引出了一个问题,即为什么内存不会被包裹在一个可以验证它本身的一致性的对象中.
那么,为什么在这种情况下使用原始指针？使用引用还是智能指针会更好吗？指针是否包含数字数据,如果是这样,将它包装在管理该指针生命周期的对象中会更好吗？
回答这些问题可以帮助您找到一种更具防御性的方法,因为您最终会得到一种更容易防御的设计.
jal*_*alf 13
防御的最佳方法是不要在运行时检查null的指针,而是避免使用可能为null的指针开始
如果传入的对象不能为null,请使用引用!或者通过价值传递它!或者使用某种智能指针.
进行防御性编程的最佳方法是在编译时捕获错误.如果将对象视为null或指向垃圾的错误,那么您应该使这些事情编译错误.
最终,您无法知道指针是否指向有效对象.因此,不是检查一个特定的极端情况(这比真正危险的情况,指向无效对象的指针远不常见),而是通过使用保证有效性的数据类型使错误无法实现.
我想不出另一种主流语言,它允许你在编译时捕获与C++一样多的错误.使用该功能.