翻译自:http://stackoverflow.com/questions/5068578/do-we-really-need-a-safe-release-macro
问:
很多人包括我自己使用类似这种的宏:
#define SAFE_RELEASE(X) [X release]; X = nil;
我在评估为什么我这样使用,并且说一下自己的观点。
我想使用这个宏的原因如果我们使用一个已经释放的对象,程序不会产生异常,因为当一个对象值为nil的时候,Object-C会忽略掉这个异常。
打击我的是这样做的话会产生一些隐晦的BUG。也许当再次使用X的时候程序崩溃掉是更好的选择,这样的话,测试的时候你可以发现这个BUG并改善你的代码。
这个宏是否鼓励lazy programing?
答1:
我想你在问题中说了正反两方面,所以我没有多少要补充的。我自己不使用这个结构。像你提议的那样,它可以能会掩饰掉不恰当的内存使用。我倾向于修正这个BUG而不是这种征兆。
因此,我有时看到的一种折中的方式是:
l 在开发期间令其崩溃
l 在最终产品代码中令var= nil
这种方式对于付费用户会更稳定可靠并且在开发期间同样会崩溃。
我同样不热衷于这种方式,因为面向用户的版本使用不同的代码只是为了使有BUG的版本保持运行,但这并不代表它在做正确的事情。没有崩溃但毁坏了你的数据库不是一个想要的行为。。。。。。
答2:
我也正在研究相同的问题。查阅一些资料后,我得到这样的方法:
#define DEBUGGING
//#definePRODUCTION
#ifdef DEBUGGING
#define SAFE_RELEASE(X) [X release];
#else
#define SAFE_RELEASE(X) [X release]; X = nil;
#endif
这样,如果我在开发阶段程序会崩溃,如果是最终产品代码则不这样。
本文深入探讨了使用Safe Release宏在内存管理中的应用与潜在风险,提出了在开发过程中如何避免此类隐晦BUG的替代策略,旨在提高代码质量和稳定性。

被折叠的 条评论
为什么被折叠?



