我们忘记了为什么“多个出口点”首先被认为是有害的吗?回到当天(在广泛访问良好的异常处理和最终构造之前,或管理像auto_ptr这样的对象,当它们离开作用域时进行清理),这是困扰许多多退出函数的问题:
int function blah(arg1, arg2)
allocate resource
if early failure detection
return failure_status
... much later...
release resource // oh rats! resource didn't release
return success_status
如果资源是内存,则会产生内存泄漏.如果它是数据库事务,我们正在走向错误的数据库争用或死锁.就此而言,随着更多异常支持的出现,我们隐式地从方法中添加了许多潜在的退出(由于未处理的异常).在我的C日里,我养成了从不调用delete的习惯,而是使用auto_ptr,以便在auto_ptr退出其作用域时清除已分配的内存,即使某些意外异常抬头.
在我们的垃圾收集Python世界中,我们仍然可以遇到这个问题,即使我们的许多对象(如文件或锁)都改进了自清洁行为.但是在CPython以外的实现中(jython和IronPython命名为2),不能保证析构函数何时被调用,因此需要在方法中构建更主动的东西.为此目的的第一个机制是try / finally:
int function blah(arg1, arg2)
allocate resource
try:
if early failure detection
return failure_status
... much later...
return success_status
finally:
release resource // always releases no matter what
但是现在Python有了上下文管理器,结合了新的’with’语法:
int function blah(arg1, arg2)
allocate resource
with context_manager(resource): // releases on exit from 'with'
if early failure detection
return failure_status
... much later...
return success_status
因此,让我们确定我们告诉整个故事,我们可以抛弃这个旧板栗的原因是新的编码实践使它变得不必要.