这个说法不准，是对实时性有要求的场合不适合用异常

用异常并不意味着降低可靠性

【 在 fanci 的大作中提到: 】
: 高可靠性的程序是不适合用异常的
: 异常主要用于业务逻辑，Python Java 那种，只需要在最外边 catch 一下记录下来然后退出。  
--
FROM 222.130.138.*

有一个帖子，简单测了性能，包括expected<T>
帖子标题：Investigating the Performance Overhead of C++ Exceptions

MS编译器组的一个哥们2006年写了个仔细分析x86、x64异常的ppt：
The Cost of C++ Exception Handling on Windows — Kevin Frei
--
修改:z16166 FROM 222.130.138.*
FROM 222.130.138.*

除非没办法，一般不用try-catch，不throw
--
FROM 120.244.162.*

单线程使用句柄，这种情况是没可能出现的

出现这种情况，通常是因为使用句柄时没保证MT-safe，也就是代码的逻辑bug。
这也是对try/catch的误用/滥用之一，用来掩盖代码的真实bug
MS在windows上更加激进，try/catch(...)可以设置为同时捕捉os异常和c++异常，极大地促进了catch(...)的滥用！
我现在看到catch(...)就反胃，对用这个的码农嗤之以鼻

这跟那些发现用FreeLibrary()来unload某些dll会崩或者卡死时，就不unload这个dll一样，顶多是个临时workaround。


还有个点是：
即便句柄没做到线程安全，线程A在用句柄时，句柄被线程B给close了，也不应该导致崩溃。这说明某个地方的处理代码没检查和这个句柄有关的API的返回值。

比如socket句柄，那是可以随便跨线程关闭的，线程A关闭这个句柄，并不会导致正在使用这个句柄的线程B、C、D崩溃，而只是导致线程B、C、D的send、recv操作失败返回而已。有的时候就是可以强行关闭socket句柄来让这些可能blocking的线程来退出的。

【 在 bn95 的大作中提到: 】
: 我以前不喜欢用，后来发现有时候是逃不掉的，不用程序会崩溃，特别是程序与外界有交互时
: 比如，如果你要操作一个windows句柄，可能出现这种情况
: 用if判断的时候，句柄是有效的
: ...................
--
修改:z16166 FROM 222.130.138.*
FROM 222.130.138.*

一句话秒了：rust 没有异常，只有 panic
c++ exception 本质还是信号捕获，不像java只需要在函数头部声明一下try..catch的地址，c++启用异常后每层函数调用都要进行系统调用，完全得不偿失

【 在 wjhtingerx 的大作中提到: 】
: 这玩意儿把出问题的调用栈都弄没了，反倒不利于调试吧？
--
FROM 114.251.196.*