- 主题:大家都用C++的try catch吗？
C++异常的主要问题是它个半拉子，拉屎拉一半。
最开始，你按照书上说的用了异常，一切都显得很高大上。
当项目变得有一点规模以后，你调一个函数，然后这个函数你不知道啥原因就会抛出一个异常，你不catch就会崩，你要catch也不知道该catch啥类型，不过你还是catch了抛出的那个。
但是它又冒出第二个、第三个、第N个异常，你开始烦了，但是你还是耐心地全部catch了一通，代码变得很冗长。
但是你发现就算你仔细看了这个函数，还是保不齐这个函数下面的函数会抛异常，于是有时候你catch(...)，有时候你又觉得应该负责任一些，于是继续往上throw
然后你的上层函数又发疯了，怎么原先好好的突然又异常了呢！算了catch(...)吧。
但是到处都catch(...)之后也很奇怪，于是你在顶层又catch(...)
然后你发现程序行为变得很诡异，总觉得哪里出错了，但是又不知道究竟是哪里出错，于是你开始注释掉catch(...)，让错误在第一时间暴露出来。
最后你发现，转了一圈你又回来了。
这就好比你去餐厅吃个饭，结果发现有的菜没货了你会死，菜上错了你会死，服务员不高兴了你会死，筷子放错方向了你会死，整个供应链无论哪里出个unhandled exception你都会死。。。
【 在 wjhtingerx 的大作中提到: 】
: 这玩意儿把出问题的调用栈都弄没了，反倒不利于调试吧？
--
修改:yuanmo FROM 221.216.117.*
FROM 221.216.117.*
就是这个道理。你一个第三方库老老实实地办事就行了，要么成功，要么失败顺便说一个失败原因，我自己会处理。
结果你办事失败了，还抛给我N种死法让我猜，猜错一个就原地爆炸。。。
【 在 mopo 的大作中提到: 】
: 一般第三方库很不识相抛异常的时候才会勉强用用，不像java能用就用
: 事实上catch后能做的动作并不多，能用c++写的大概率偏底层，这种时候出异常了，除非是网络和I/O可以重试一下，其他严重错误还不如死了重新拉起来
--
FROM 221.216.117.*
java是因为你必须catch所有异常才能编译通过，虽然麻烦，但是好歹是清晰的。C++就纯粹看你心情想不想catch，想catch几个。如果你想catch，对不起你要是漏了几个它也不会告诉你。
python是因为它本来就有无数错误要到运行期才发现，这边变量名错了那边函数参数没对上，raise出来的异常只是其中一小部分，虱子多了不咬。而且出错了反正就是当时就把栈信息告诉你了，debug代价也还可以。C++一崩，先给你来个几G的dump，然后你慢慢调去。
【 在 lwp 的大作中提到: 】
: 没看明白
: 你说的这个问题跟c++有什么关系
: java/py/js不为什么不会出现这种情况？
: ...................
--
修改:yuanmo FROM 220.207.87.*
FROM 220.207.87.*
因为C++的异常就是根本就搞不清楚，或者说它是一个既要又要还要的乌托邦式的设计。
就算你认为你搞清楚了，那也只是你觉得你清楚了。你用的库，你的同事，你的上级你的下属，都有自己各自的理解和习惯，大概率人家还觉得你的理解不对呢。
一个无法达成共识的东西，那就是设计有问题，不要怪这一届的用户不行。
【 在 smartbear 的大作中提到: 】
: 你压根没搞清楚这个用在什么地方
--
FROM 220.207.87.*
这些库的作者是牛人，他们用经过深思熟虑的异常无所谓（虽然我个人也不太喜欢）。
不过现实公司里面的996工具人们，以SB居多。你无法用牛人的要求去要求你周围的那帮SB们，并且其实那帮SB同时也觉得你是一个更大的SB。。。你也无法要求996的社畜们在满足产品经理的朝令夕改的奇葩要求的同时，还要维护一个完美的文档。就算你写了完美的文档，对不起你的SB同事们是不会看文档的。
【 在 z16166 的大作中提到: 】
: 你的意思是boost、qt这些库的作者都是SB吗，这两个东西是使用异常的
: 抛了异常，但是事先没提供对应的文档说明，才值得骂吧
--
FROM 220.207.87.*
CPP大佬写的是那种千万程序员都要用的库，考虑用起来要方便，所以会精雕细琢，这当然是好的。
而实际开发的现实情况不是这样，作为一个制定技术规范的人，你要考虑的核心是如何在有限资源有限时间内把软件弄出来，并且各种指标要达标、要健壮、能应对千变万化的需求。
应届毕业生中，哪怕是985毕业的，能当场写对冒泡排序的人都是少数，90%根本就没用过异常。这就是现实。一个项目代码量经常会超过百万行，千万行甚至数十亿行都不罕见，并且这些代码绝大多数都是功能性代码，很多精雕细琢的考虑在这个时候会完全失效。如何在一个草台班子写的代码里面避免出现屎山，最直接的办法是两条：
1. 你有个好的架构设计，把各种功能解耦了，就算出现问题也不要扩大化。
2. 你有个简明的编程规范，大家很容易理解并遵循的那种。
很遗憾，C++异常的设计，“大多数”情况下对上面任何一条都是破坏性的。
【 在 z16166 的大作中提到: 】
: 最坏情况下无非就是找各种借口（最常用的借口就是工期）堆shi山
: 但是在shi山上呆久了，觉得整个世界就只有shi山，甚至还要阻止别人爬出shi山，那就有点搞了
: 我根本没兴趣管谁用不用c++异常、滥用还是用得好，只是说cpp大佬推荐用异常（这也是C++板块以前有人提醒我的）。但是你看这楼里还是有一些人抱的是陈旧观点，以为现在的c++异常还需要用指令来建立异常帧，那也算澄清了一下
: ...................
--
FROM 220.207.87.*