群聊：项目级的错误处理

CFANS·镇宅神兽(58135482) 17:44:35
说到错误处理，路神

CFANS·镇宅神兽(58135482) 17:44:46
我最近一直在想这个东西

非常路<luzte@qq.com> 17:45:12
恩,你说

CFANS·镇宅神兽(58135482) 17:47:04
你说，程序的错误，是可以恢复或者处理的嘛，代码的逻辑上是可以发现和修改，最终从项目代码里排除，但是向内存不够申请失败，还有就是通信时对方服务器的错误产生错误的响应，这些错误该咋个处理

非常路<luzte@qq.com> 17:47:43
内存申请失败..工程上,这种问题是不需要处理的

非常路<luzte@qq.com> 17:48:02
那是理论上会失败...,实际上遇到这种情况,我至今没遇到过

非常路<luzte@qq.com> 17:48:29
因为内存不够会用swap

非常路<luzte@qq.com> 17:48:37
swap也不够,才会出错..

非常路<luzte@qq.com> 17:49:41
这是极其少的情况..当然,你的软件如果是类似memcached之类的,那就需要内存管理来分配,不光是更高效的使用..从设计上也能避免这个问题

非常路<luzte@qq.com> 17:50:02
如果是通讯错误,那是架构设计的必须要考虑的问题..

非常路<luzte@qq.com> 17:50:35
这东西有很多方式了,比如连接出错,应该怎么处理,网络中断应该怎么处理..

非常路<luzte@qq.com> 17:50:47
这就不是三言两语能讲清楚的

CFANS·镇宅神兽(58135482) 17:51:10
嗯

非常路<luzte@qq.com> 17:51:16
这是服务器架构的"故障处理"的整个设计的机制的问题了

非常路<luzte@qq.com> 17:51:29
以后等以后再说会比较好

非常路<luzte@qq.com> 17:51:58
你问的实质都是架构问题..

CFANS·镇宅神兽(58135482) 17:52:04
我是觉得对于一个项目来说，一定要有项目级的错误处理机制，这个错误机制应该能够处理项目里常见的一些错误

非常路<luzte@qq.com> 17:52:22
这跟C语言无关..各个语言都有这个问题

李斌.北界.upsilon<ben.upsilon@gmail.com> 17:52:45
这是神马问题来着,,,,

CFANS·镇宅神兽(58135482) 17:52:46
然后特定的错误，再由发生这个错误的特定模块自己处理

非常路<luzte@qq.com> 17:52:50
一般来说,代码级的错误处理机制,用log就可以了

非常路<luzte@qq.com> 17:53:17
然后写一个子系统专门来监视这种故障机制

CFANS·镇宅神兽(58135482) 17:53:24
就是不处理，曾经发生了某个错误？

非常路<luzte@qq.com> 17:53:41
发生了错误,不见得你能处理

非常路<luzte@qq.com> 17:53:53
主要的是你要知道,有这个问题,而且知道大概怎么回事

非常路<luzte@qq.com> 17:53:56
这比较重要

非常路<luzte@qq.com> 17:54:22
没有人能设计出一个完全没问题的系统.....

CFANS·镇宅神兽(58135482) 17:54:40
然后写一个子系统专门来监视这种故障机制，咱们讲讲这个吧

非常路<luzte@qq.com> 17:54:41
而且写代码的人..又不是一个..

非常路<luzte@qq.com> 17:54:58
这是工程考虑方法...

非常路<luzte@qq.com> 17:55:20
工程的角度,一定要考虑这是多人配合,水平有高有低..重要的是你要知道..

非常路<luzte@qq.com> 17:55:35
就用log做一下记录,最简单的方式是记录到文本..

非常路<luzte@qq.com> 17:55:49
如果要做成较为完善的系统,那肯定是记录到数据库..

非常路<luzte@qq.com> 17:56:04
另外一端,就获得数据库记录的信息..

非常路<luzte@qq.com> 17:56:41
也没什么可讲的,做成web系统什么的,能看到,你要表达的好一点,用一点图形来显示什么的

非常路<luzte@qq.com> 17:56:56
这只是一个思路,没技术可讲

萧萧(413113278) 17:57:22
做一个反馈系统吗

非常路<luzte@qq.com> 17:57:30
差不多就这个意思

非常路<luzte@qq.com> 17:57:35
其实跟运维的系统一个意思

萧萧(413113278) 17:57:37
闭环自动控制

CFANS·镇宅神兽(58135482) 17:58:02
在C++里，我可以在入口加一个try-catch，把所有的错误集中到一起处理

CFANS·镇宅神兽(58135482) 17:58:04
C呢

非常路<luzte@qq.com> 17:58:10
当然,如果是系统崩了

非常路<luzte@qq.com> 17:58:19
你就可以考虑发短信什么的

非常路<luzte@qq.com> 17:58:36
try-catch,并不是好的错误处理机制

萧萧(413113278) 17:58:59
以前测试用继电器

 

非常路<luzte@qq.com> 17:59:02
还不如C语言的,if(error(xx)){
handle_error;
}

非常路<luzte@qq.com> 17:59:04
立即处理

非常路<luzte@qq.com> 17:59:19
try-catch的逻辑是

非常路<luzte@qq.com> 17:59:27
把错误统一往上抛

非常路<luzte@qq.com> 17:59:50
直到一个表现层,然后达到一个专门处理错误的层面..

非常路<luzte@qq.com> 17:59:57
实际而言,这其实没什么必要

萧萧(413113278) 18:00:07
死机了，就用继电器重启系统

非常路<luzte@qq.com> 18:00:10
有错误立即处理..

非常路<luzte@qq.com> 18:00:23
因为错误处理这东西,没办法,用分层结构处理

非常路<luzte@qq.com> 18:00:37
扔上去,上层写代码的人,不一定理解这个错误

非常路<luzte@qq.com> 18:00:52
谁写的代码谁处理错误,这其实最符合实际的

CFANS·镇宅神兽(58135482) 18:00:56
C的语言立即处理，还是要提前知道可能会发生什么错误，并且这种错误怎么处理都是提前清楚的吧

非常路<luzte@qq.com> 18:01:19
异常也是要提前知道

幻影(715473413) 18:01:40
try catch，可以简化处理流程

非常路<luzte@qq.com> 18:01:46
不然你统一一个catch(exception E)

CFANS·镇宅神兽(58135482) 18:04:08
哦，理解有差异，clean code说要把错误处理集中起来

非常路<luzte@qq.com> 18:04:24
不要苛求这种..ZMQ的作者现在写C++完全用C的方式在写

非常路<luzte@qq.com> 18:04:31
错误处理全部改成C的方式

幻影(715473413) 18:04:35
没异常机制的情况下，每一步都必须做错误分支处理

非常路<luzte@qq.com> 18:04:42
对于系统级的应用,立即处理比较好

非常路<luzte@qq.com> 18:05:01
这倒是没有..

非常路<luzte@qq.com> 18:05:06
反而是异常处理情况下..

幻影(715473413) 18:05:12
ZMQ作者说的那个侵入式的链表

CFANS·镇宅神兽(58135482) 18:05:16
就是路神，和clean code的作者，对于错误处理代码是否要集中，存在本质上的分歧

幻影(715473413) 18:05:17
其实C++里也有解决方案的

非常路<luzte@qq.com> 18:05:21
你几乎不做处理,你还要做try-catch

非常路<luzte@qq.com> 18:05:23
很烦

非常路<luzte@qq.com> 18:05:40
你try-catch的目的就是往上层throw

非常路<luzte@qq.com> 18:05:47
我现在越来越觉得这个机制,不是很好用

幻影(715473413) 18:06:04
不过我一般不用异常，哈哈

非常路<luzte@qq.com> 18:06:25
比如你A,B,C三层

非常路<luzte@qq.com> 18:06:37
C层发生出错,但是你在A,C中建构了一个B层

非常路<luzte@qq.com> 18:06:46
B层的代码是不需要做错误处理的

非常路<luzte@qq.com> 18:07:07
问题在于....A,B,C之间..B必须做传递异常处理的事情,这样A才知道

非常路<luzte@qq.com> 18:07:18
这很烦的..= =

非常路<luzte@qq.com> 18:07:23
代码反而不clean

非常路<luzte@qq.com> 18:07:50
try-catch肯定不是良好的设计

非常路<luzte@qq.com> 18:08:04
除非是haskell的mona.

非常路<luzte@qq.com> 18:08:15
mona处理这事,会显得很优美

非常路<luzte@qq.com> 18:08:43
monad..

CFANS·镇宅神兽(58135482) 18:09:00
也可以发生错误的地方throw一下，但是各层都不处理，但是最外层有一整套错误处理代码

CFANS·镇宅神兽(58135482) 18:09:10
这样好吗

非常路<luzte@qq.com> 18:09:13
monad的功能也是做传递的..当然不单单是错误处理的传递,还有IO的传递

非常路<luzte@qq.com> 18:09:24
你试试就知道了

非常路<luzte@qq.com> 18:09:31
try-catch的本意是这样

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:09:32
aop吧………

非常路<luzte@qq.com> 18:09:36
代码实际来看,很烦

非常路<luzte@qq.com> 18:09:56
有一些代码..只是调用一个API而已...

非常路<luzte@qq.com> 18:10:21
你根本没错误处理..但是你被迫要写try-catch throw

非常路<luzte@qq.com> 18:10:36
后来你就会发现,你几乎每个函数都有 try-catch throw

非常路<luzte@qq.com> 18:10:49
java代码,有一些就是这样的,斌叔是不是?

非常路<luzte@qq.com> 18:11:16
最蛋疼的表现形式是

非常路<luzte@qq.com> 18:11:38
你的函数就两行代码..错误处理,需要五行,而且什么都没做.....

非常路<luzte@qq.com> 18:11:45
只是为了传递到上层

非常路<luzte@qq.com> 18:12:29
所以现在真正实际用异常集中做处理错误的人,工程上非常少

非常路<luzte@qq.com> 18:12:36
因为这个设计比较挫

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:12:40
那是我最吐槽的

非常路<luzte@qq.com> 18:12:54
理论上集中处理当然比较好

非常路<luzte@qq.com> 18:13:05
现实有点问题...

CFANS·镇宅神兽(58135482) 18:13:16
我记得，A->B->C 。如果C异常了，B没有处理代码，就会自动扔到A里

CFANS·镇宅神兽(58135482) 18:13:31
A再没处理，程序就会挂掉

非常路<luzte@qq.com> 18:13:36
我记得不会..= =

CFANS·镇宅神兽(58135482) 18:13:44
囧

CFANS·镇宅神兽(58135482) 18:13:56
晚上我写个C#代码看看

非常路<luzte@qq.com> 18:14:05
因为没办法知道,你是哪层的

非常路<luzte@qq.com> 18:14:11
我不是说C是一个类

非常路<luzte@qq.com> 18:14:16
B是一个类..

非常路<luzte@qq.com> 18:14:22
我说的是一层.....

CFANS·镇宅神兽(58135482) 18:14:36
层的意思是。。。

非常路<luzte@qq.com> 18:14:49
比如整个MODEL为一层..

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:14:51
囧

CFANS·镇宅神兽(58135482) 18:15:36
我觉得应该也是可以的...

CFANS·镇宅神兽(58135482) 18:15:48
晚上我确认下

非常路<luzte@qq.com> 18:15:51
你不往上抛..这根本不知道应该不应该处理异常

非常路<luzte@qq.com> 18:16:21
往上抛是让上面的程序员,知道,这东西不处理,简直不能通过

非常路<luzte@qq.com> 18:16:50
要不然是,这个C出错了,C发生问题..

非常路<luzte@qq.com> 18:16:58
这跟立即处理有什么区别..= =

逐梦<aninfeel@qq.com> 18:17:15
可以再抛

非常路<luzte@qq.com> 18:17:17
那只是把调用stack给显示出来

非常路<luzte@qq.com> 18:17:52
这两者最大的区别是,往上抛了之后,你必须要处理之..

非常路<luzte@qq.com> 18:18:16
斌叔,我记得不是很清楚..

非常路<luzte@qq.com> 18:18:23
java的语法是这样的,是必须要处理的

逐梦<aninfeel@qq.com> 18:18:26
看框架怎么处理了，一般到了controller层还继续抛的话，就到error页面了

非常路<luzte@qq.com> 18:18:31
你确认一下,是不是?

CFANS·镇宅神兽(58135482) 18:18:32
问个问题，处理之后，还能回到错误发生点，继续逻辑的执行吗

CFANS·镇宅神兽(58135482) 18:18:39
貌似不可以了吧

非常路<luzte@qq.com> 18:19:05
不可以

逐梦<aninfeel@qq.com> 18:19:20
哪里像继续就在哪里处理

非常路<luzte@qq.com> 18:19:21
理论上可以..但是没提供这样的功能

非常路<luzte@qq.com> 18:19:33
因为汇编级是可以做到的

CFANS·镇宅神兽(58135482) 18:19:36
即便错误处理了，这个执行流程就结束了

CFANS·镇宅神兽(58135482) 18:20:04
要继续执行，只能再看一个新流程

非常路<luzte@qq.com> 18:20:06
错误处理实质跟协程的机制是一样的

非常路<luzte@qq.com> 18:20:14
内部原理都是这样的

非常路<luzte@qq.com> 18:20:22
我先保存函数的场景

非常路<luzte@qq.com> 18:20:24
然后我跳出去...

非常路<luzte@qq.com> 18:20:31
处理其他的,然后回来

非常路<luzte@qq.com> 18:20:51
协程的是,我不回来了..= =

非常路<luzte@qq.com> 18:21:56
在逆向工程领域,就利用windows自带的异常处理SEH

非常路<luzte@qq.com> 18:22:06
做一些执行流程的改变

非常路<luzte@qq.com> 18:22:38
因为你随便跳,虽然可以跳过去,比如指针指向过去,问题是场景(context)怎么办法

非常路<luzte@qq.com> 18:23:09
代码的执行包括一堆"场景",即代码的环境

非常路<luzte@qq.com> 18:23:56
理论上是可以的..但是没提供这样的功能

CFANS·镇宅神兽(58135482) 18:24:33
明白了，函数之所以能从被调函数回来继续执行，是因为保存了执行环境

非常路<luzte@qq.com> 18:24:45
恩..

CFANS·镇宅神兽(58135482) 18:24:50
而异常没有

非常路<luzte@qq.com> 18:24:54
因为进程才是实质的执行单位

非常路<luzte@qq.com> 18:25:14
异常也不是没有,异常也有它的"环境"

CFANS·镇宅神兽(58135482) 18:25:41
收益匪浅，我出去一趟，今天很感谢路神~~大家继续聊，我回来看记录，哈哈哈

非常路<luzte@qq.com> 18:25:51
异常类似实现了一个回调机制

非常路<luzte@qq.com> 18:27:07
异常触发之后..

非常路<luzte@qq.com> 18:27:19
然后程序执行的流程会忽然改变

非常路<luzte@qq.com> 18:27:52
然后跳到一个专门过滤异常的地方,然后筛选出异常,找到对应的处理块,回调回来,处理之

非常路<luzte@qq.com> 18:28:05
是这么一个机制..

非常路<luzte@qq.com> 18:28:50
所以异常给人的感觉是"触发式"

非常路<luzte@qq.com> 18:29:45
而且还可以处理,不会跟错误处理一样忽然中断了程序..

非常路<luzte@qq.com> 18:29:55
你的代码可以被系统回调使用

非常路<luzte@qq.com> 18:30:29
如果忽视这个异常,还能执行流程还能跳回来

非常路<luzte@qq.com> 18:30:44
仔细想想是不是这么回事

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:31:56
这不是finally么

非常路<luzte@qq.com> 18:32:21
不止是finlly

非常路<luzte@qq.com> 18:32:25
catch也是这样

非常路<luzte@qq.com> 18:32:59
这个机制跟C的错误处理不一样的是..比如是C的指针错误

非常路<luzte@qq.com> 18:33:06
就break了

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:33:07
指针....

非常路<luzte@qq.com> 18:33:23
这就是C的错误处理方式

非常路<luzte@qq.com> 18:33:37
你是没办法,你想说就让你随便乱指呗

非常路<luzte@qq.com> 18:33:41
也是不行的

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:33:51
啊啊啊啊啊.一个星期的动画都没看...

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:33:56
赶紧补上

非常路<luzte@qq.com> 18:34:05
如果是异常是可以的..你写一个空的block,就可以跳过这个错误

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:34:15
-,-

非常路<luzte@qq.com> 18:34:30
程序可以继续执行的(当然这可能会有更大的问题)

非常路<luzte@qq.com> 18:35:23
但是从这点细细体会的话..异常是有流程跳转或者说改变流程的能力

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:35:57
记得csdn上面也说过..不过变成骂战了...

非常路<luzte@qq.com> 18:36:11
??什么情况?

非常路<luzte@qq.com> 18:36:16
是什么说过

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:36:18
主张catch改变流程和不改变流程...

非常路<luzte@qq.com> 18:36:32
......

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:36:53
把catch入侵到业务逻辑代码去..

非常路<luzte@qq.com> 18:36:55
不改变流程那些傻逼,估计是没看过SEH...

非常路<luzte@qq.com> 18:37:13
哦,是说设计层面啊

非常路<luzte@qq.com> 18:37:25
适度的用一下也挺好的

非常路<luzte@qq.com> 18:37:51
现在的人思维太西化..什么东西都太讲原则..

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:38:06
比如年龄,catch了错误的输入,然后直接return NaN..感觉很那啥

非常路<luzte@qq.com> 18:38:08
做事的方式,是可以灵活处理的

非常路<luzte@qq.com> 18:38:37
python界,有时候用异常不当异常来用

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:38:49
有些人不是这么想,非得if isNum才return..

ALENS(蓝)(398667606) 18:38:56

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:39:12
我就吐槽了..这用得着骂战么...

非常路<luzte@qq.com> 18:39:28
python用异常检测数组的key

非常路<luzte@qq.com> 18:39:50
有时候只是为了查这个没有的话,我就跳过

非常路<luzte@qq.com> 18:40:04
为什么跳过..因为那是map function的用法

非常路<luzte@qq.com> 18:40:11
用来做switch结构

媚惑桃花(9422399) 18:40:26 

switch被map替代?

非常路<luzte@qq.com> 18:41:01
python大量的使用map来做switch,依赖的就是有异常和lambda这东西..

非常路<luzte@qq.com> 18:41:17
yad

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:41:46
那是好物啊,,,苦逼的我还在考虑java怎么搞这模拟呢

非常路<luzte@qq.com> 18:42:18
不可能

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:42:40
哈哈....

非常路<luzte@qq.com> 18:42:48
java太静态了

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:43:11
就是说java太static了..

非常路<luzte@qq.com> 18:43:13
php就缺异常

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:43:20
我都不知道怎么模拟

非常路<luzte@qq.com> 18:43:23
不然就可以使用这个技巧了

非常路<luzte@qq.com> 18:43:44
PHP一旦key出问题..

非常路<luzte@qq.com> 18:43:51
程序就终止了..

非常路<luzte@qq.com> 18:44:04
= =..哪还弄个毛

非常路<luzte@qq.com> 18:44:22
不过还是可以弄..

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:44:24
噗....php不带这么傲娇啊

非常路<luzte@qq.com> 18:44:37
@array[$function]

非常路<luzte@qq.com> 18:44:49
禁止报错,不准报错..= =

ALENS(蓝)(398667606) 18:44:57

非常路<luzte@qq.com> 18:45:02
这就可以了..PHP是一个受

非常路<luzte@qq.com> 18:45:10
你攻,她就受

李斌.北界.upsilon<ben.upsilon@gmail.com> 18:45:15
我笑岔气

幻影(715473413) 21:18:22 

刚才台式机 直接烫的关机了

 

幻影(715473413) 21:27:30
我不小心碰了一下机箱，结果风扇变得好吵

 

光风(907964774) 21:28:20
和我冰箱一样 我不小心碰了下 结果好吵

ALENS(蓝)(398667606) 21:28:48
拿铁锤碰下就不会再吵了

逐梦<aninfeel@qq.com> 21:57:25
妈的，kindeditor不愧是国货

逐梦<aninfeel@qq.com> 21:57:40
怎么让它不过滤自定义样式啊

___De/pch(415718351) 21:57:43
怎么了

逐梦<aninfeel@qq.com> 21:59:13
总是，慎用国货

非常路<luzte@qq.com> 22:36:15
国人对技术的用途的认知方面,有很大的问题...

ALENS(蓝)(398667606) 22:36:40
科技是第一生产力

非常路<luzte@qq.com> 22:36:41
爆难用,爆难二次开发什么的,都不要惊讶

非常路<luzte@qq.com> 22:37:08
一切都是性能惹的祸...

逐梦<aninfeel@qq.com> 22:37:34
不直接改代码都不能用

非常路<luzte@qq.com> 22:37:38
国人面对 性能和扩展性,一般会优先选择性能...

逐梦<aninfeel@qq.com> 22:37:54
完全没灵活性可言

___De/pch(415718351) 22:37:54
～

非常路<luzte@qq.com> 22:37:58
这种认知..吐槽无力

非常路<luzte@qq.com> 22:38:31
我已经吐槽多次了..

非常路<luzte@qq.com> 22:39:02
比如DZ这种论坛,是不可能改好的..

非常路<luzte@qq.com> 22:39:15
就算以后升级到版本 20都是不可能的..

非常路<luzte@qq.com> 22:39:21
= =..就这幅德行

逐梦<aninfeel@qq.com> 22:40:11
代码还是不错的，比tinymce好多了，但是……怎么感觉作者没有概括思想呢

___De/pch(415718351) 22:40:57
是向上设计的

非常路<luzte@qq.com> 22:41:35
最麻烦的是,他们还引以为荣..

非常路<luzte@qq.com> 22:41:40
说这是"技术"

非常路<luzte@qq.com> 22:41:52
技术TMD个妹

非常路<luzte@qq.com> 22:42:11
我说直接一点,这就叫做技术差..

ALENS(蓝)(398667606) 22:43:00
用户多那

非常路<luzte@qq.com> 22:43:05
你很少见到一个作家会觉得

转载于:https://www.cnblogs.com/code-style/archive/2012/09/16/2687130.html