真是怕了那些用异常捕捉却不抛出错误的人了！

[LiuSha]

这两天在改别人写的代码，要增加新的功能，但真是改得太痛苦了，因而想吐槽一下。

• 一个类几千行（ python ），界面和功能写在一个类里了；
• 大段大段的代码没有注释，还有一些命名类似的方法也没有注释；
• 最恶心人的地方就是滥用异常捕捉还不抛出错误，导致调试的时候明明程序出 bug 了却没有任何错误信息。

唉，说完了，明天还得接着改。

[Raymon111111]

最恶心的应该是第一点吧

[l4ever]

说的应该不是我, 我一般捕获了错误一定会打日志.

[hmxxmh]

Python 写起来是真舒服，维护起来是真要命，唉，动态语言的弊端吧

[sun1991]

这种人就是没责任心, 想着只要不出错就可以混过去.

[wdv2ly]

逮住再放，那为啥要逮🐶

[chendy]

曾经一个项目（ Java ），里面到处都是空的 catch (Exception e) 块
问那个老哥为啥这么写，他说不这么写编译不了

[zjsxwc]

和 js 相比，Python 写起来不舒服，维护起来要人命

[ebingtel]

@wdv2ly 可以收敛异常类型的个数、表名错误的原因……总不能在最外层加个 Exception 或者每个异常加个 XXXError

[rooob1]

@zjsxwc 引战？

[pmispig]

哈哈哈，终于有人开这个标题了，我要狠狠地吐槽一番。
我们公司几乎大部分的人都是这样做的，
try {
}catch (Excetpion){
log("XX 业务异常异常")
}
妈蛋，我简直醉了

[LiuSha]

@hmxxmh 如果注意代码规范就还好一些，就怕乱写一通的，维护起来要人命了

[zunceng]

别吐槽 python 了，
golang 这么强制的语言还有人不处理 err 呢
res, _ = sess.Insert(model)

[hdbzsgm]

@pmispig #10 对于某些 Checked Exception 这样做是合适的 但是直接 catch Exception 的人 应该立刻辞退

[julyclyde]

@chendy Java 虽然强制 catch，但是依然拯救不了外行

[gam2046]

Check Exception 本质上是要求编码人员遵守一定的规范，而人这个变量太无法控制了，导致很多经验不足的人空捕获异常，使得 CE 形同虚设，但我觉得这是人的问题，而不是 CE 本身的问题。

[kop1989]

很多语言不支持异常声明吧，导致抛出错误的沟通成本很高。

[laravel]

php 才是最好的语言，laravel 是最好的框架。

[LuciferGo]

我司引入自动代码检查了，这种全都要打回去重写，不改不准提测，哈哈哈哈

[LiuSha]

@LuciferGo 厉害了！

[evlos]

某大厂的 JS SDK 就是这样，简直不能更弱智了

[pmispig]

@hdbzsgm catch Exception 我不反对，问题是你得把异常堆栈抛出来呀，这样直接吃掉了，谁知道底层是什么原因呢。。

[BBCCBB]

@hmxxmh 我不信加上 type hints 还恼火

[neoblackcap]

因为绝大多数人是不知道错误应该怎么处理。
举个例子，比如我要处理一下 Excel 文件，然后往里面写入一个名为报告的工作表。
第一步 Excel 文件就不存在，应该如何处理？

很多人受不能抛出异常，不能抛出错误的说法影响。好像程序一直跑着就是正常的，就是没有 bug。
其实有问题不能处理就应该往上层抛，尽量保持事发当时的环境。这样才是正常的做法。假如最上层都不能解决的，那么就应该赶紧打日志然后崩溃。阻止进一步的错误发生。

正是因为不了解错误处理，所以才那么多那么多空的异常处理，仅仅为了糊弄编译器。

[rioshikelong121]

Let it crash.

[augustheart]

其实这种情况下很多时候是不知道怎么处理吧……
要是每个错误都一定有合适的处理方法，一个个处理都没问题，但是问题是相当多的异常根本无从处理，直接崩了拉倒……

[stevenkang]

恕我直言，业务层面处理异常就是渣架构。明明可以靠架构来处理，非得每个业务点都来 try catch 一把。

[CallMeReznov]

我自己写的 python 到是直接 try 所有
不过如果用到线上的话 不精确捕捉的确说不过去吧

[RYAN0UP]

同，前公司某同事吧几百行代码写在 try 里面却不处理异常，不打印堆栈。

[Achiii]

想去写 py

[miaoxia]

见过最崩溃的代码，就是用 try-catch 当作业务判断，catch 到不同的 exception 处理不同的业务
因为这事儿大吵一架

[luckylo]

我来说一句吧。 一个类 11K 行代码 。 一个函数 四五百行 代码，基本没注释。 Java

[hmxxmh]

@BBCCBB 类型注解是 3.6 版本之后才有的吧，好像返回类型啥的只能自我约束，程序不会去判断。。。，而且很多项目还是 2.7 的

[AS4694lAS4808]

给自己挖的坑，本来想写个小测试工具，catch 块就直接空着了。后来忘了并且把这个功能合并到生产版本。。花了几天在线上找问题，找到后差点打死自己。。

[BBCCBB]

@hmxxmh 嗯嗯, 3.5 开始加的..

[arrow2015]

我司代码有安全规范，不让 catch 中打印堆栈错误信息。

[Biscuits]

每次我想吐槽同事的时候就会想到：我怎么会和他是同事的？

[sessionreckon]

这种还好吧...
来了头条之后,我才发现原来代码可以写的那么烂
if else 里面的代码有的是不能跑的,class 没有定义,对象没有定义,func 不存在
大部分看起来都是代码在迭代的时候,原来的代码不删导致的,维护者知道进不去就不管了
所以代码在 IDE 上到处飘红...
但是又不是不能用,Python 跑的挺正常的....

[LiuSha]

@sessionreckon 大厂也会有这种情况吗。。。

[MonoLogueChi]

我以前也经常这么做，就是为了程序运行的时候不被卡死了

[darrenfang]

@pmispig #10 我司上古代码连 log 都没有，哈哈哈哈

[mostkia]

@neoblackcap 是的，发生了没法处理的错误，首先得保留现场，一般是抛出错误，这样后期维护调试时才能发现问题所在。其次，假如已经发生了致命错误，就不能够继续执行下去，因为后续的程序不知道会因为当前的错误而发生什么更严重的异常，同时及时停止出错的程序，也能减少报错量，吧问题停止在出问题的地方，而不是到最后得到一长串莫名其妙的报错，利于后期快速定位排查问题。

[mostkia]

@pmispig 直接自己定义一个自己当时能看懂的错误，然后把宝贵的编译器报错直接丢掉，牛批。

[zappos]

python 没有 partial class，写成两个类只能用继承了

[zappos]

@darrenfang 如果能自定义流也成。。。有些上古程序硬是往 stderr 里面写，我这边 popen 总是捕获不到。

[zappos]

@neoblackcap gui 是 longrunning 的东西，不崩才比较重要吧。。。

一个回调出了异常，为什么要整个 ui 都崩掉，就好比服务器，一个 handler 出了异常，为啥要让整个服务器都崩掉？

再说了异常这种东西，没准过段时间就好了。

[neoblackcap]

@zappos 我由头自尾都没有谈到 GUI 的问题。

处理不了就要崩掉，你数据库连接不了。不崩掉，然后能正常运行？每个程序总有你处理不了的异常，这个时候不打日志崩掉还追求所谓 long running，那才是奇怪。

记住不是盲目追求长时间运行，或者一小问题都要崩掉。这是两个极端。

错误处理应该是，这层不能处理就应该往上层传递，最上层都处理不了了那么就要打日志崩掉。能处理的话，那么就正常处理就好了。好比你举得例子，你 handler 抛出的异常，你能处理，那么就处理啊。不能处理就打日志崩掉啊。难道你还想说不能处理的就当没事发生？

[zappos]

@neoblackcap 哦？？ spring 是这么做的嘛？ apache server 是这么做的嘛？

[zappos]

gui 程序控制在回调一级就够了。可以把每个回调视为独立的东西，彼此不互相影响。

由于 gui 框架基本不提供 spring 那种异常统一处理的功能，回调级的 try-catch 根本不能避免。而且除了打 log 也没别的办法。

[realpg]

个人开发规范：

因为传进来的外部数据非法原因导致的错误
比如类型不对 比如传进了空 比如传进了的数据库连接异常
扔异常 大部分是自定义异常 class

因为自身逻辑失败导致的异常，如果功能自身是主线逻辑，直接 crash
如果自身是支线逻辑 扔异常 依然是自定义异常 class

比如一个数据存储模块，目标目录不可写或者已满导致写不进去，直接 crash
如果是一个存日志的支线模块，同样目标目录不可写，丢个 OPLogDirCannotWriteException 让上层决定这个日志不可写是不是重要要不要中断程序