转自:http://www.disandu.com/archives/1181
今天工作时无意中写出了这样的代码
bool func()
{
try {
......
return true;
}
catch() {
return false;
}
}
写完这支代码后,我意识这应该是不好的实现手法,多个返回位置,尤其是在异常中还带返回值,这个写法有点奇怪。到底这样写到底行不行? 带着这个疑问,我在搜索框输入了“Put return in catch",搜到了stackoverflow上的这篇文章:Return in catch block? stackoverflow上的筒子们讨论得很热烈,代码是C#的,与CPP大同小异。首先是一个筒子提出一个疑问,与我的问题类似:
Is is wrong to have a return statement in a catch block? What are the alternatives?i.e:public bool SomeFunction() { try { //somecode return true; } catch(Exception ex) { MessageBox.Show(ex.message); return false; } }
马上有网友回答,当然是可以的,无论是从语法角度还是实现方法的角度,有人在沙发位置接贴,上面函数有多个出口(return),可读性更好的写法如下:
public bool SomeFunction() { bool success = true; try { //somecode } catch(Exception ex) { MessageBox.Show(ex.message); success = false; } return success; }
上面的实现方式还有待改进,沙发筒子又说,“Logged exceptions are a lot more reliable than user's recounts of what happened.”,
用日志记录异常比让用户发现软件的异常显得更健壮。
我非常同意这个说法,实际上异常是软件本身的问题造成的,不应该给用户施压。 改进的代码如下:
bool success = true;
try { DoTheImportantThing(); DoTheOtherThingThatMightFailButWeDontCare(); } catch (DontCareAboutItException ex) { log.Info(ex);
success = false; } catch (Exception ex) { log.Error(ex);
success = false;
}
return success;
上面的代码似乎很完美,但是有时候我们会感觉操作像"success"这样的返回值变量是件麻烦事,而且遇到了多个异常需要处理时,
每个catch里塞一条"success=false"其实是很烦琐的。
所以上面的代码还可以更简洁:
try { //somecode return true; }
catch (DontCareAboutItException ex) { log.Info(ex);
} catch (Exception ex) { log.Error(ex); }
return false;
上面这段代码虽然有多个出口,但代码更简洁可读,这样做是值得的。到此,这个问题
我算是理明白了,但stackoverflow上的筒子们还不满意,他们继续纠结于C#里的
finally和return谁前谁后的问题,我等 做CPP开发在一 旁窃笑 ,因为CPP的发明人
Bjarne Stroustrup早就说过:
In a system, we need a "resource handle" class for each resource. However, we don't have to have an "finally" clause for each acquisition
of a resource. In realistic systems, there are far more resource acquisitions than kinds of resources, so the "resource acquisition is
initialization" technique leads to less code than use of a "finally" construct.
具体的原因可见这篇文章 :为何C++不提供“finally”结构?[链接已失效]