- 主题:异常这玩意儿当初是哪个脑残发明出来的？
这应该属于你自己精神洁癖了哈哈。
得为自己的自由买单啊。
【 在 speedboy2998 的大作中提到: 】
: 导致我不得不用异常，污染了我。
--
修改:hgoldfish FROM 120.37.21.*
FROM 120.37.21.*
确实。处理错误都是脏活累活。觉得烦很正常。
每个语言和软件系统里面总有一些这种看了觉得烦的东东。
【 在 z16166 的大作中提到: 】
: 这不可能，那可能做的就是改变自己的观念，做到不再觉得用异常就是自己被污染了，哈哈
: 用返回码何尝不是一种被“污染”，各种库定义各种返回码
--
FROM 120.37.21.*
确实。。异常应该是能不能就不用。
我觉得两个地方用异常非常的好：
1. 申请内存失败。
2. 协程退出。
其它地方用异常都值得商榷。包括 IO 错误啥的，都属于非常常见的场景，不应该用异常。
【 在 overcomeunic 的大作中提到: 】
: 实在理解不了stoi抛异常的支撑是啥，这是为了异常而异常啊
--
FROM 120.37.21.*
我怎么感觉心智负担降低了？
因为阅读代码的时候，只要关注主业务流程，而不是需要去关注出错了怎么办。
【 在 ensonmj 的大作中提到: 】
: 异常是通过栈回溯一层层检查，非常耗时，肯定比返回值判断满。唯一的好处就是写代码的人不用每一层写这个check，但给读代码的人带来了极大的心智负担，因为你很难找到这个异常有没有处理，哪儿处理的，就是个巨大的飞线。如果飞线多了那就成面条了。
--
FROM 120.37.21.*
C++ 本来就不会阻止有人吞枪自尽啊。
像你这种情况，我觉得也不属于主流程的异常情况。不值得去考虑。
【 在 ensonmj 的大作中提到: 】
: 不，我就碰到过有人拿catch异常，然后修改状态去走另外一条路的代码。如果看代码不关心他怎么处理异常就根本搞不懂他在干嘛。
: 另外，pytorch里面也有这么干的
--
修改:hgoldfish FROM 120.37.21.*
FROM 120.37.21.*
我倒是认为 IO 错误不应该用异常来表示。因为 IO 错误太常见了。我们做网络开发的，时时都要注意网络断了数据包发不出去。
我喜欢最喜欢的异常是 bad_alloc，这个异常抛出来之后，对于程序员基本上啥事都不需要处理，直接整个程序崩溃掉就行。完全没有思维负担，这样的异常谁不喜欢啊。
我另外只使用两个异常，一个是 timeout 异常，一个是 kill 协程异常。这两个功能必须使用异常才能做好:
try {
Timeout _(5.0);
doSomething();
} catch (TimeoutException &) {
// 处理超时。
}
在以上代码里面，无论 doSomething() 里面有多少层级的调用。都能够准确地在 5 秒左右就超时跳出来。使用其它方案很难做到。
kill 协程的话，向协程抛出异常，然后让协程继续运行。这样协程就会从中断点——一般是 IO 读取位置退出。不用异常恐怕也很难做到这样。
基本上，我就用这三个异常。其它的我都不用。
【 在 mopo 的大作中提到: 】
: 除了IO exception老实说没多少有价值的异常
--
修改:hgoldfish FROM 117.28.110.*
FROM 117.28.110.*
代码搞 RAII 就行了啊。
【 在 gameplayer 的大作中提到: 】
: 像你说的场景，它是怎么实现的？不会造成资源泄露吗？
--
FROM 117.28.110.*
我日常使用 timeout 都是在协程里面用的。
这个 timeout 的实现也是协程对回调的巨大优势。
【 在 speedboy2998 的大作中提到: 】
: 现在都是异步 IO，没有谁的代码在这里傻傻地等 N 秒吧。
: 我觉得调用异步 IO，设置一个回调，不管是 IO 成功了或者异常了，都在回调函数里处理，检测状态码就行。。不比异常好更多?
: 异常最大的问题是：程序的逻辑思维变得支离破碎。
: ...................
--
FROM 117.28.110.*
出错概率很大的话就应该用返回值啊。强制程序员的各层代码里面都要考虑 IO 出错的可能性。
我看很多程序员都不考虑写 buf 只写入一半的场景。所以现在好多系统函数会特别弄个强制要求程序员处理返回值的警告。特别是涉及到安全的 setuid() 这种。这是非常好的习惯。
其实不止程序员是这样的。操作系统自己也有问题, close() 也应该有返回值的啊。
【 在 yuanmo 的大作中提到: 】
: 我总结的适用于异常的地方就是，那种出错概率很大，出错原因很多，且出错现场和处理错误现场距离很远的场合。这种情况下靠层层返回值检查逐级上报，会非常麻烦。
: 诸如网络IO错误是我们认为比较适合的地方，当然这个可能跟你们使用的方式不一样，以及上层处理策略也不一样。
--
FROM 14.19.13.*
对了，我也没有看过。之前在本版有提到过, amd65 架构下使用下使用查表实现。那么应该是 throw 没有开销，catch 也没有开销，但 try 有开销吧？
另外, i386, arm32 和 arm65 架构下的开销不知道怎么样呢？
【 在 z16166 的大作中提到: 】
: 哪些是私货？
: 有些人连guru的书都没读过，对异常的看法完全凭自己的经验和猜测，这才是可怕的地方。
: 之前有人连异常的实现，都不舍得花时间反汇编看看（也可能看不懂汇编），就断言还是每个函数有prolog和epilog的大开销
: ...................
--
修改:hgoldfish FROM 14.19.13.*
FROM 14.19.13.*