问一下大家都怎么使用try catch，有点乱。。
一直以来对try catch的使用都不得其法。倒不是使用本身的困惑，关键是如果分层设计的时候，try 。。catch到底该怎么用呢。
例如：
Func1（）       -------假设为界面的函数
{
  Func2（）；
}

Func2（）        ----假设为控制层的函数
{
Func3（）；
}

 Func3（）        ----假设为最底层
{
  
}

在使用try catch的时候，大概怎么使用比较合适。是否有一个比较合适的机制，能让程序比较系统性。否则，导出都是try catch，感觉好乱啊。也不知道捕获了异常是继续抛出，还是显示一个用户看得懂的信息。

敬请高人点拨一下。


------解决方案--------------------
每一层丢出每一层的异常，将内侧的异常包装在InnerException。
------解决方案--------------------
考虑发布时“分层”问题。如果你们是发布一个产品框架（一组DLL）给成千上万程序员使用，那么你们可以统一地在测试之前做出计划——一共有多少种error，例如20种，然后规范所抛出的异常的信息。

否则如果跟这种平台发布无关，那么基本上，我建议尽可能地删除try....catch。实际上只有在需要自己“像个鸵鸟一样把脑袋藏在沙子里”的时候你才需要让try...catch运行，而且此时也不是为了抛出异常信息而是为了掩藏异常信息。

如果try...catch不是为了掩藏异常信息、而是为了抛出信息，那么其实就是制造了“感觉好乱”。没有好处，而且让调试器无法立即定位到真正的异常代码上。
------解决方案--------------------
Func1（）       -------假设为界面的函数
{
  Func2（）；
}

Func2（）        ----假设为控制层的函数
{
Func3（）；
}

 Func3（）        ----假设为最底层
{
  try catch finally(确保数据库一定要关闭的机制，当然可以使用using这语法糖)
//从这点可以得出，非托管资源一定要保证资源释放，
//但你在catch 不要干什么 还是直接throw
}

其他的最好不用用了，如果你的程序经常抛异常，那么说明思考得还不全面~

------解决方案--------------------
try catch是一种异常抛出机制，理论上来讲，任何你觉得会存在错误的语句都可以添加try catch,调试程序的时候可以借助抛出的异常来排错，程序真正发布之后，这并不是一个很好的解决方案，应该尝试去底层解决这些异常。