类似数学公式如果检查每个分母不得为零,每个根号里不得为负之类的, 就太繁琐了, 总体上减少了代码量(相对于返回值检查)的异常就是合理的, 增加了代码量就是过度设计


【 在 ensonmj 的大作中提到: 】
异常是通过栈回溯一层层检查，非常耗时，肯定比返回值判断满。唯一的好处就是写代码的人不用每一层写这个check，但给读代码的人带来了极大的心智负担，因为你很难找到这个异常有没有处理，哪儿处理的，就是个巨大的飞线。如果飞线多了那就成面条了。  
  
【 在 ziqin (子青|会挽雕弓如满月|西北望|射天狼) 的大作中提到: 】
:  业务场景不一样，很多错误不是调用api的直接caller可以处理的，反馈链太长代码没法处理。
:  
:  一个很简单的例子就是：
:  
--
FROM 103.216.43.*

除了IO exception老实说没多少有价值的异常
--
FROM 219.142.253.*

我倒是认为 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.*

现在都是异步 IO，没有谁的代码在这里傻傻地等 N 秒吧。
我觉得调用异步 IO，设置一个回调，不管是 IO 成功了或者异常了，都在回调函数里处理，检测状态码就行。。不比异常好更多?

异常最大的问题是：程序的逻辑思维变得支离破碎。


【 在 hgoldfish 的大作中提到: 】
: 我倒是认为 IO 错误不应该用异常来表示。因为 IO 错误太常见了。我们做网络开发的，时时都要注意网络断了数据包发不出去。
: 我喜欢最喜欢的异常是 bad_alloc，这个异常抛出来之后，对于程序员基本上啥事都不需要处理，直接整个程序崩溃掉就行。完全没有思维负担，这样的异常谁不喜欢啊。
: 我另外只使用两个异常，一个是 timeout 异常，一个是 kill 协程异常。这两个功能必须使用异常才能做好:
: ...................
--
FROM 218.76.62.*