对于Try..Catch的一点疑问，欢迎讨论

Question

刚看到蜗牛的帖子• 嵌套异常处理　　开发人员喜欢在方法的末尾加上异常处理的嵌套方法，如：
C# codepublic class NestedExceptionHandling
{
public void MainMethod()
{
try
{
//some implementation
ChildMethod1();
}
catch (Exception exception)
{
//Handle exception
}
}private void ChildMethod1()
{
try
{
//some implementation
ChildMethod2();
}
catch (Exception exception)
{
//Handle exception
throw;}
}private void ChildMethod2()
{
try
{
//some implementation
}
catch (Exception exception)
{
//Handle exception
throw;
}
}
}
　　如果相同的异常被处理多次，上面的代码会发生什么?毫无疑问，性能开销将会剧增。　　解决办法是让异常处理方法独立出来，如：
C# codepublic class NestedExceptionHandling
{
public void MainMethod()
{
try
{
//some implementation
ChildMethod1();
}
catch(Exception exception)
{
//Handle exception
}
}private void ChildMethod1()
{
//some implementation
ChildMethod2();
}private void ChildMethod2()
{
//some implementation
}
}我想问的是：在三层架构中，是不是应该只有UI层才需要Try..Catch?
理由：因为DAL,BLL中的异常都可以通过UI层的调用捕捉到异常。

Answer 1

实际运用中， 通常会在异常发生的最近的地方catch并且做一定的处理然后throw， 然后在程序的边界点集中处理,像你这个例子中， ChildMethod2 也应该catch， 然后打log， wrap成自定义的异常， 然后throw

Answer 2

个人感觉应该减少使用try catch，另外谁产生的异常，谁来处理，不用都抛给UI。

Answer 3

我认为catch (Exception exception)
{
//Handle exception
throw;
}catch 后又throw就没必要catch了

Answer 4

try是非常耗资源的。最差的情况下。会有三秒左右。

Answer 5

类库开发的一个原则是不应该吞噬任何异常，如果涉及资源释放，或者需要记录异常日志，那么使用 try，然后重新抛出，不用太纠结性能问题。

Answer 6

并非如此吧，throw;是回避异常，但程序仍然继续执行。
如果是throw exception的话，就是主动抛出异常了。

Answer 7

我一般都是底层一直throw,在UI处理！
不过感觉这样不太好！但习惯了

Answer 8

我认为，除非对异常做额外处理，比如添加一些当前的变量信息等包装一个新异常，或者做回滚操作等。其他的，在非UI层都不要做额外的异常处理，特别是有些程序员的习惯很令人费解：try{}catch(Exception ex){throw ex;}这样既没意义又浪费资源还导致调试困难。