try catch 异常处理

学习code：

int  main( int  argc,  char   *  argv[])
... {
  try ...{
... ...
  }
  catch(std::exception& e) ...{
    std::cerr << "Exception caughted:" << std::endl
      << e.what ()
      << std::endl;
  }
  catch(...) ...{
    std::cerr << "Exception caughted:" << std::endl
      << "unknown exception caughted."
      << std::endl;
  }

  return 0;
}  

搜集的解释：

try和catch必须成对出现，都是由程序员自已来处理异常，不过在IDE环境下都是先响应系统异常处理，再响应用户异常处理。脱离IDE环境，让程序单独运行，就只响应用户异常处理__try是用在C中，try是用在C++中。

  try  
      程序代码  
   
  catch（错误类型1）  
        //如果出错，错误类型位catch参数中的错误类型，执行此段程序  
  catch（错误类型2）  
        //如果出错，错误类型位catch参数中的错误类型，执行此段程序  
  end   try  

在C++ 中使用异常处理，一般情况下是在你让为可能出现错误的地方，用try块将其包含在其中，以便捕获异常。但是也不能在程序设计中过度的使用异常处理。下面是一些不使用异常的原则：
1、不要在异步事件中使用异常。
2、不要在处理简单错误的时候使用异常。
3、不要将异常用于程序的流程控制。
4、不要强迫自己使用异常。

关于异常的advice，我来小小翻译一下：《C++ Pragramming Language》
1。使用异常作为“出错”处理2。如果local的控制流本身就可以处理，那就不要使用异常，因为异常是处理不同单元之间消息传递的机制。
3。在使用异常的代码中，使用“资源分配即初始化”的技术来管理资源。比如将资源申请放入某个代理类的初始化中，将资源释放放入代理类的析构中，然后用这个代理来管理资源
4。不是所有的程序都需要是异常安全的。资源可以不被主动释放，比如你可以放心的将内存资源的释放交给操作系统（通过abort等）
5。可以使用“资源分配即初始化”的技术和异常处理来保持不变性。比如：保证异常发生前后环境不变，对于local变量可以通过代理释放资源，对于local以外的变量可以在catch后的异常处理中将内容恢复。
6。最小化try块的使用（能不用就不用）。不要在异常处理中释放资源，应使用“资源分配即初始化”的技术。
7。不是每个函数都需要处理所有的错误。
8。在构造函数中，抛出异常来暗示资源分配失败。这比构造函数设置一种失败的状态要好得多，清晰的多。
9。除非已经出现不可恢复的问题，不要在拷贝构造函数中抛出异常。因为拷贝构造函数通常涉及到两个操作：释放默认资源，获取新的资源。如果抛出异常，就很难恢复到拷贝构造前的状态。
10。不要在析构函数中抛出异常
11。在Main（）函数中扑获所有异常
12。普通的代码和异常处理的代码不要耦合在一起。
13。确保构造函数获取的资源在析构函数里被释放
14。保持资源管理的结构层次。即不同层次的资源的获取和释放不要相互干涉。
15。使用”异常规范“作为主要的接口。即将模块的异常规范以接口的形式提供给模块的使用者，这也可以提高异常处理的效率和命中率。
16。要意识到，由new分配的内存不会在异常处理中释放掉。
17。如果一个程序可能抛出异常也可能不抛出，在使用这个程序时，最好是假设他会抛出异常（必要在不同模块之间产生不必要的耦合关系）
18。不是所有异常都继承自类exception
19。作为一个函数库，在出错的时候不应该一厢情愿的将程序关掉，而是应该通过抛出异常，将出错消息传达给他的使用者。异常正是在不同模块之间传递出错消息的很好的机制。
20。作为一个函数库，他不应该将出错诊断信息显示在IO设备上，比如stderr，他不应该对用户使用的设备作假定（或许，用户已经把stderr关掉了，或是根本就没有标准的显示终端），而应该是通过异常机制。
21。在设计阶段早期就安排好出错处理的策略。

如果有认识不妥的地方，大家一起来讨论一下。

 

更为详细的介绍：异常处理编程 王胜祥

http://loveunix.com/viewthread.php?tid=47543

或者
http://sa.csai.cn/tszl/wangshengxiang.asp