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

[LiuSha]

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

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

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

[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 让上层决定这个日志不可写是不是重要要不要中断程序