这两天在改别人写的代码,要增加新的功能,但真是改得太痛苦了,因而想吐槽一下。
唉,说完了,明天还得接着改。
1
Raymon111111 2020-01-09 20:26:38 +08:00 2
最恶心的应该是第一点吧
|
2
l4ever 2020-01-09 20:34:40 +08:00 1
说的应该不是我, 我一般捕获了错误一定会打日志.
|
3
hmxxmh 2020-01-09 21:57:07 +08:00 via Android
Python 写起来是真舒服,维护起来是真要命,唉,动态语言的弊端吧
|
4
sun1991 2020-01-09 22:54:44 +08:00
这种人就是没责任心, 想着只要不出错就可以混过去.
|
5
wdv2ly 2020-01-10 07:52:21 +08:00 via Android
逮住再放,那为啥要逮🐶
|
6
chendy 2020-01-10 08:18:51 +08:00 10
曾经一个项目( Java ),里面到处都是空的 catch (Exception e) 块
问那个老哥为啥这么写,他说不这么写编译不了 |
7
zjsxwc 2020-01-10 08:37:33 +08:00
和 js 相比,Python 写起来不舒服,维护起来要人命
|
8
ebingtel 2020-01-10 08:41:43 +08:00
@wdv2ly 可以收敛异常类型的个数、表名错误的原因……总不能在最外层加个 Exception 或者每个异常加个 XXXError
|
10
pmispig 2020-01-10 09:12:49 +08:00
哈哈哈,终于有人开这个标题了,我要狠狠地吐槽一番。
我们公司几乎大部分的人都是这样做的, try { }catch (Excetpion){ log("XX 业务异常异常") } 妈蛋,我简直醉了 |
12
zunceng 2020-01-10 10:00:53 +08:00
别吐槽 python 了,
golang 这么强制的语言还有人不处理 err 呢 res, _ = sess.Insert(model) |
13
hdbzsgm 2020-01-10 10:17:30 +08:00
@pmispig #10 对于某些 Checked Exception 这样做是合适的 但是直接 catch Exception 的人 应该立刻辞退
|
15
gam2046 2020-01-10 10:25:20 +08:00
Check Exception 本质上是要求编码人员遵守一定的规范,而人这个变量太无法控制了,导致很多经验不足的人空捕获异常,使得 CE 形同虚设,但我觉得这是人的问题,而不是 CE 本身的问题。
|
16
kop1989 2020-01-10 10:26:32 +08:00
很多语言不支持异常声明吧,导致抛出错误的沟通成本很高。
|
17
laravel 2020-01-10 10:27:18 +08:00
php 才是最好的语言,laravel 是最好的框架。
|
18
LuciferGo 2020-01-10 10:36:04 +08:00 1
我司引入自动代码检查了,这种全都要打回去重写,不改不准提测,哈哈哈哈
|
20
evlos 2020-01-10 11:00:32 +08:00 via Android
某大厂的 JS SDK 就是这样,简直不能更弱智了
|
21
pmispig 2020-01-10 11:30:21 +08:00
@hdbzsgm catch Exception 我不反对,问题是你得把异常堆栈抛出来呀,这样直接吃掉了,谁知道底层是什么原因呢。。
|
23
neoblackcap 2020-01-10 13:06:19 +08:00 1
因为绝大多数人是不知道错误应该怎么处理。
举个例子,比如我要处理一下 Excel 文件,然后往里面写入一个名为报告的工作表。 第一步 Excel 文件就不存在,应该如何处理? 很多人受不能抛出异常,不能抛出错误的说法影响。好像程序一直跑着就是正常的,就是没有 bug。 其实有问题不能处理就应该往上层抛,尽量保持事发当时的环境。这样才是正常的做法。假如最上层都不能解决的,那么就应该赶紧打日志然后崩溃。阻止进一步的错误发生。 正是因为不了解错误处理,所以才那么多那么多空的异常处理,仅仅为了糊弄编译器。 |
24
rioshikelong121 2020-01-10 13:35:37 +08:00
Let it crash.
|
25
augustheart 2020-01-10 13:39:41 +08:00
其实这种情况下很多时候是不知道怎么处理吧……
要是每个错误都一定有合适的处理方法,一个个处理都没问题,但是问题是相当多的异常根本无从处理,直接崩了拉倒…… |
26
stevenkang 2020-01-10 13:57:23 +08:00
恕我直言,业务层面处理异常就是渣架构。明明可以靠架构来处理,非得每个业务点都来 try catch 一把。
|
27
CallMeReznov 2020-01-10 14:04:11 +08:00
我自己写的 python 到是直接 try 所有
不过如果用到线上的话 不精确捕捉的确说不过去吧 |
28
RYAN0UP 2020-01-10 14:05:20 +08:00 via iPhone
同,前公司某同事吧几百行代码写在 try 里面却不处理异常,不打印堆栈。
|
29
Achiii 2020-01-10 14:12:54 +08:00
想去写 py
|
30
miaoxia 2020-01-10 15:07:45 +08:00
见过最崩溃的代码,就是用 try-catch 当作业务判断,catch 到不同的 exception 处理不同的业务
因为这事儿大吵一架 |
31
luckylo 2020-01-10 15:15:05 +08:00
我来说一句吧。 一个类 11K 行代码 。 一个函数 四五百行 代码,基本没注释。 Java
|
32
hmxxmh 2020-01-10 15:48:49 +08:00
@BBCCBB 类型注解是 3.6 版本之后才有的吧,好像返回类型啥的只能自我约束,程序不会去判断。。。,而且很多项目还是 2.7 的
|
33
AS4694lAS4808 2020-01-10 15:56:45 +08:00
给自己挖的坑,本来想写个小测试工具,catch 块就直接空着了。后来忘了并且把这个功能合并到生产版本。。花了几天在线上找问题,找到后差点打死自己。。
|
35
arrow2015 2020-01-10 18:36:52 +08:00 via Android
我司代码有安全规范,不让 catch 中打印堆栈错误信息。
|
36
Biscuits 2020-01-10 18:39:14 +08:00
每次我想吐槽同事的时候就会想到:我怎么会和他是同事的?
|
37
sessionreckon 2020-01-10 18:43:49 +08:00
这种还好吧...
来了头条之后,我才发现原来代码可以写的那么烂 if else 里面的代码有的是不能跑的,class 没有定义,对象没有定义,func 不存在 大部分看起来都是代码在迭代的时候,原来的代码不删导致的,维护者知道进不去就不管了 所以代码在 IDE 上到处飘红... 但是又不是不能用,Python 跑的挺正常的.... |
38
LiuSha OP @sessionreckon 大厂也会有这种情况吗。。。
|
39
MonoLogueChi 2020-01-10 20:27:39 +08:00 via Android
我以前也经常这么做,就是为了程序运行的时候不被卡死了
|
40
darrenfang 2020-01-11 09:25:29 +08:00
@pmispig #10 我司上古代码连 log 都没有,哈哈哈哈
|
41
mostkia 2020-01-11 12:11:42 +08:00
@neoblackcap 是的,发生了没法处理的错误,首先得保留现场,一般是抛出错误,这样后期维护调试时才能发现问题所在。其次,假如已经发生了致命错误,就不能够继续执行下去,因为后续的程序不知道会因为当前的错误而发生什么更严重的异常,同时及时停止出错的程序,也能减少报错量,吧问题停止在出问题的地方,而不是到最后得到一长串莫名其妙的报错,利于后期快速定位排查问题。
|
43
zappos 2020-01-11 12:55:22 +08:00 via Android
python 没有 partial class,写成两个类只能用继承了
|
44
zappos 2020-01-11 12:57:01 +08:00 via Android
@darrenfang 如果能自定义流也成。。。有些上古程序硬是往 stderr 里面写,我这边 popen 总是捕获不到。
|
45
zappos 2020-01-11 12:59:55 +08:00 via Android
@neoblackcap gui 是 longrunning 的东西,不崩才比较重要吧。。。
一个回调出了异常,为什么要整个 ui 都崩掉,就好比服务器,一个 handler 出了异常,为啥要让整个服务器都崩掉? 再说了异常这种东西,没准过段时间就好了。 |
46
neoblackcap 2020-01-11 13:16:34 +08:00
@zappos 我由头自尾都没有谈到 GUI 的问题。
处理不了就要崩掉,你数据库连接不了。不崩掉,然后能正常运行?每个程序总有你处理不了的异常,这个时候不打日志崩掉还追求所谓 long running,那才是奇怪。 记住不是盲目追求长时间运行,或者一小问题都要崩掉。这是两个极端。 错误处理应该是,这层不能处理就应该往上层传递,最上层都处理不了了那么就要打日志崩掉。能处理的话,那么就正常处理就好了。好比你举得例子,你 handler 抛出的异常,你能处理,那么就处理啊。不能处理就打日志崩掉啊。难道你还想说不能处理的就当没事发生? |
47
zappos 2020-01-11 19:25:19 +08:00 via Android
@neoblackcap 哦?? spring 是这么做的嘛? apache server 是这么做的嘛?
|
48
zappos 2020-01-11 19:29:36 +08:00 via Android
gui 程序控制在回调一级就够了。可以把每个回调视为独立的东西,彼此不互相影响。
由于 gui 框架基本不提供 spring 那种异常统一处理的功能,回调级的 try-catch 根本不能避免。而且除了打 log 也没别的办法。 |
49
realpg 2020-01-12 14:12:09 +08:00
个人开发规范:
因为传进来的外部数据非法原因导致的错误 比如类型不对 比如传进了空 比如传进了的数据库连接异常 扔异常 大部分是自定义异常 class 因为自身逻辑失败导致的异常,如果功能自身是主线逻辑,直接 crash 如果自身是支线逻辑 扔异常 依然是自定义异常 class 比如一个数据存储模块,目标目录不可写或者已满导致写不进去,直接 crash 如果是一个存日志的支线模块,同样目标目录不可写,丢个 OPLogDirCannotWriteException 让上层决定这个日志不可写是不是重要要不要中断程序 |