0 前言
个别初学者学习编码和[错误处理]时,先晓得[编程语言]有一种处理错误的模式或约定(如Java就抛异样),而后就开始用这些工具。但却漠视这问题实质:处理错误是为了写正确程序。可是
1 啥叫“正确”?
由解决的问题决定的。问题不同,解决方案不同。
如一个web接口承受用户申请,参数age,兴许业务要求字段是0~150之间整数。如输出字符串或正数就必定不承受。个别在后端某地做输出合法性检查,不过就抛异样。
但归根到底这问题“正确”解决办法总是要以某种模式提醒用户。而提醒用户是某种前端工作,就要看界面是app,H5+AJAX还是相似于[jsp]的服务器产生界面。不论啥,你要依据需要去”设计一个修复谬误“的流程。如一个常见的流程要后端抛异样,而后一路到某个集中处理错误的代码,将其转换为某个HTTP的谬误(业务错误码)提供给前端,前端再映射做”提醒“。如用户输出非法申请,从逻辑上后端都没法本人修复,这是个“正确”的策略。
2 报500了嘞!
如用户上传一个头像,后端将图片发给[云存储],后果云存储报500,咋办?你可能想重试,因为兴许仅是[网络抖动],重试就能失常执行。但若重试屡次有效,若设计了某种热备计划,可能改为发到另一个服务器。“重试”和“应用备份的依赖”都是“立即解决“。
但若重试有效,所有的[备份服务]也有效,兴许就能像下面那样把谬误抛给前端,提醒用户“服务器开小差”。从这计划易看出,你想把谬误抛到哪里是因为那个catch的中央是解决问题最不便的中央。一个问题的解决方案可能要几个不同的错误处理组合起来能力办到。
3 NPE了!
你的程序抛个NPE。这个别就是程序员的bug:
- 要不就是程序员想表白一个货色”没有“,后果在后续解决中忘判断是否为null
- 要不就是在写代码时感觉100%不可能为null的中央呈现了一个null
不论哪种,这谬误用户总会看到一个很含混的报错信息,这远远不够。“正确”方法是程序员本人能尽快发现它,并尽快修复。要做到这点,须要[监控零碎]一直爬log,把问题报警进去。而非等用户找客服投诉。
4 OOM了!
比方你的[后端程序]忽然OOM挂了。挂的程序没法复原本人。要做到“正确”,须在服务之外的容器思考这问题。
如你的服务跑在[k8s],他们会监控你程序状态,而后重启新的服务实例补救挂掉的服务,还得调整流量,把去往宕机服务的流量切换到新实例。这的复原因为跨零碎所以不能仅用异样实现,但情理一样。
但光靠重启就“正确”了?若服务是齐全无状态,问题不大。但若有状态,局部用户数据可能被执行一半的申请搞乱。因而重启要注意先“复原数据到非法状态”。这又回到你要晓得咋样才是“正确”的做法。只依附简略的语法性能不能无脑解决这事。
5 晋升维度
- 一个工作线程的“内部容器“是管理工作线程的“master”
- 一个网络申请的“内部容器”是一个Web Server
- 一个用户过程的“内部容器”是[操作系统]
- Erlang把这种supervisor-worker的机制融入到语言的设计
Web程序很大水平能把异样抛给顶层,是因为:
- 申请来自前端,对因为用户申请有误(数据合法性、权限、用户上下文状态)造成的问题,最终根本只能通知用户。因而抛异样到一个集中处理错误的中央,把异样转换为某个业务错误码的办法,正当
- 后端服务个别无状态。这也是软件系统设计的个别准则。无状态才意味着可随时随地安心重启。用户数据不会因为因为下一条而会出问题
- 后端对数据的批改依赖DB的事务。因而一个改一半的、没提交的事务不会造成副作用。
但这3条件并非总成立。总能遇到:
- 一些解决逻辑并非无状态
- 也并非所有的数据批改都能用一个事务爱护
尤其要留神对[微服务]的调用,对内存状态的批改是没有事务爱护的,一不留神就会搞乱用户数据。比方上面代码段
6 难以排查的代码段
try { int res1 = doStep1(); this.status1 += res1; int res2 = doStep2(); this.status2 += res2; // 抛个异样 int res3 = doStep3(); this.status3 = status1 + status2 + res3;} catch ( ...) { // ...}
先假如status1、status2、status3之间需保护某种不变的束缚(invariant)。而后执行这段代码时,如在doStep3抛异样,上面对status3的赋值就不会执行。这时如不能将status1、status2的批改rollback,就会造成数据违反束缚的问题。
而程序员很难发现这个数据被改坏了。坏数据还可能导致其余依赖这数据的代码逻辑出错(如本来应该给积分的,却没给)。而这种谬误个别很难排查,从大量数据里找到不正确的那一小段何其艰难。
7 更难搞定的代码段
// controllervoid controllerMethod(/* 参数 */) { try { return svc.doWorkAndGetResult(/* 参数 */); } catch (Exception e) { return ErrorJsonObject.of(e); }}// svcvoid doWorkAndGetResult(/* some params*/) { int res1 = otherSvc1.doStep1(/* some params */); this.status1 += res1; int res2 = otherSvc2.doStep2(/* some params */); this.status2 += res2; int res3 = otherSvc3.doStep3(/* some params */); this.status3 = status1 + status2 + res3; return SomeResult.of(this.status1, this.status2, this.status3);}
难搞在于你写的时候可能认为doStep1~3这种货色即便抛异样也能被Controller里的catch。
在svc这层是不必解决任何异样,因而不写[try……catch]理所当然。但实际上doStep1、doStep2、doStep3任何一个抛异样都会造成svc的数据状态不统一。甚至你一开始都能够通过文档或其余沟通确定doStep1、doStep2、doStep3一开始都是必然可胜利,不会抛错的,因而你写的代码一开始是对的。
但你可能无法控制他们的实现(如他们是另外一个团队开发的[jar]提供的),而他们的实现可能会改成抛错。你的代码可能在齐全不自知状况下从“不会出问题”变成“可能出问题”…… 更可怕的相似代码不能正确工作:
void doWorkAndGetResult(/* some params*/) { try { int res1 = otherSvc1.doStep1(/* some params */); this.status1 += res1; int res2 = otherSvc2.doStep2(/* some params */); this.status2 += res2; int res3 = otherSvc3.doStep3(/* some params */); this.status3 = status1 + status2 + res3; return SomeResult.of(this.status1, this.status2, this.status3); } catch (Exception e) { // do rollback }}
你认为这样就会解决好数据rollback,甚至感觉这种代码优雅。但实际上doStep1~3每一个中央抛错,rollback的代码都不一样。
得这么写
void doWorkAndGetResult(/* some params*/) { int res1, res2, res3; try { res1 = otherSvc1.doStep1(/* some params */); this.status1 += res1; } catch (Exception e) { throw e; } try { res2 = otherSvc2.doStep2(/* some params */); this.status2 += res2; } catch (Exception e) { // rollback status1 this.status1 -= res1; throw e; } try { res3 = otherSvc3.doStep3(/* some params */); this.status3 = status1 + status2 + res3; } catch (Exception e) { // rollback status1 & status2 this.status1 -= res1; this.status2 -= res2; throw e; } }
这才是失去正确后果的代码,在任何中央出错都能保护数据一致性。优雅吗?
看起来很丑。比go的if err != nil还丑。但要在正确性和优雅性取舍,必定毫不犹豫选前者。作为程序员不能间接认为抛异样可解决任何问题,须学会写出有正确逻辑的程序,哪怕很难且看起来丑。
为达成高正确性,你不能总将本人大部分注意力放在“所有都OK的流程“,而把谬误看作是可轻易应酬了事的工作或简略的置信exception可主动搞定所有。
8 总结
对错误处理要有敬畏之心:
- Java因为Checked Exception设计问题不得不防止应用
- 而Uncaughted Exception切实弱鸡,不能给程序员提供更好帮忙
因而,程序员在每次抛错或者处理错误的时候都要三省吾身:
- 这个谬误的解决是正确吗?
- 会让用户看到啥?
- 会不会搞乱数据?
不要认为本人抛个异样就完事了。在[编译器]不能帮上太多忙时,好好写UT来爱护代码可怜的正确性。
请多写正确的代码!
本文由博客一文多发平台 OpenWrite 公布!