c++中需要异常吗？以前去面试，被问到一个问题，c++中可以不用异常处理吗？直接从代码里进行处理吗？就是不用th
c++中需要异常吗？
以前去面试，被问到一个问题，c++中可以不用异常处理吗？直接从代码里进行处理吗？就是不用throw,try,catch这些，当时没答出来，现在问一下。
visual c++
[解决办法]
http://stackoverflow.com/questions/4975504/zero-cost-exception-handling-vs-setjmp-longjmp
现在的编译器大都采用zero cost model(LLVM, gcc, vc)
很多古老的观念都该更新一下了
现在的编译器主要是用"zero cost"的技术来实现exception
意思是如果没有exception发生的话，执行代价为零；有exception发生的话，执行代价会很高
但是exception既然能被称作exception,就代表这些例外发生的机率应该要很低（远低于1%）
exception用的好，代码执行效率反而比古典的错误处理机制效率更高
而且能换取更容易阅读，维护的代码
[解决办法]这是要根据项目或者工程的需求来看，C++是完全支持异常处理的
如果需要将一些异常信息直观的反馈给上层应用，异常应该是其中的一种途径；
同时异常的使用，会带来很大的性能开销。
[解决办法]我们不用，主要还是执行效率有影响。
[解决办法]不用异常机制，那就需要用返回值指出是否有错误了。而检查返回值很繁琐，也增大了代码。异常机制跟不处理错误比较的话肯定对性能有些影响，毕竟增加了一些机制，但是与处理错误值相比，性能应该不会差。
[解决办法]异常只在异常的时候使用，不会影响决定性能。 异常不能经常发生，否则就是正常情况，不该使用异常。
不要使把异常与错误混了。
[解决办法] 那会非常麻烦的。需要注册异常回调函数（可以看成是软件中断）。这样就会非常麻烦了，当异常处理代码需要用到产生异常的上层函数的局部变量的时候就会非常麻烦，代码可读性变差、同时也会破坏封装（需要用结构体包装需要传递的相关变量给异常回调函数用）。那个结构体对于这两个函数以外的其他代码来说往往是无意义的。优化也不如try那种可以直接传局部变量的容易做到。
如果你想好看，可以用系统的__try\__catch\__final\__except了。。作用和try-catch机制类似，而且支持结构化异常。不过这算不算“不使用throw,try,catch这三个关键字”？？
另外不知道需不需要澄清一下：函数返回错误状态不是异常。异常只是指抛出的这种，而抛出异常的结果是函数不经过返回手续而直接析构局部对象然后退栈，这和按错误状态返回是不同的（有些人还搞不清楚，以为只要是错误返回和抛出的exception都是异常。。。简直没法沟通。。。）
真正需要考虑的倒是这种，其中的innerinvoke是一个具体行为未知的函数：
void func1()
{
stat_inc();
innerinvoke();
stat_dec();
return;
}
如果抛出异常的话，执行的顺序是这样的：
call func1
{
stat_inc();
innerinvoke();
exception...
结果是stat_dec()得不到调用。后面的状态就全都会乱掉了。。
在下面放什么检测代码是不现实的。因为从抛出异常的那一个点开始，正常代码都不会执行，包括你的检错代码。
结果改成这样：
void func1()
{
try
{
stat_inc();
innerinvoke();
stat_dec();
}
catch(...)
{
stat_dec();
throw;
}
return;
}
但是如果innerinvoke();根本不会抛出异常呢，那这个try块写了只会是白白消耗运行时间，虽然开销很低但是还是有。。总之就是不爽。。
写也不好不写也不好。。
我们需要一个通用的解决方案。。
结果改成这样：
void func1()
{
class _stack_proc
{
~_stack_proc()
{
stat_dec();
};
} stack_proc_val;
stat_inc();//觉得“美感不够”可以写到_stack_proc的构造函数里。
innerinvoke();
return;
}
没有异常的时候，功能和最开始那个完全一样；而如果innerinvoke包含有异常的可能，当异常抛出时，因为stack_proc_val对象的退栈就会导致stat_dec的调用。这样不管有无异常，结果都是正确的，也不会再没有异常的环境里产生额外的运行时开销
[解决办法]无语。。。
13楼居然都被人无视了。。
[解决办法]
楼上说你被无视了.....我特意来顶你....
