这篇的标题我又没有太能看懂，大体的意思是尽早失败比带着错误运行要好。不过内容中有两点挺值得回味。
第一是“这不可能心态”，也就是很多事情做了想当然的设定，忽略了一些可能的分支，这个事情我感受更多的是发生在BA描述solution的时候：
比如说这一轮有个story，叫用一个订单的销售单号去找到相同销售单号的其他订单然后根据结果做后续的处理......乍一看挺合理，不过仔细想想是有问题的，因为销售单号是货物的属性，根据我们的设计，一个订单可以有多种货物，当然理论上来说也有多个销售单号的可能，既然存在这样的可能上述的描述就存在问题，应该要改成，用一个订单的去找到与他的销售单号存在交集的订单然后根据结果.....
我们的BA同学很多时候会忽略这样的不同，因为可能在他的使用场景用法中一个订单只有一个销售号。但从产品来说，这并不是不可能发生的事，我认为应该在需求层面明确。所以BA不能仅仅从需求的角度考虑方案，要结合系统的实现逻辑来出解决方案。
第二个叫什么时候该catch exception，这个话题要展开的点挺多，也有些争议，不过书中给出了最没有争议的一种情况，就是你catch 了exception，仅仅记录了log，然后又抛出了新的exception，既然catch了为了抛新的exception，那为啥不让他直接向外抛，有一个最外层的log机制就行了，不需要繁琐的catch，记log，再抛，造成重复处理异常，没有必要的浪费资源。
在我们程序中估计是存在一些类似的情况，比如说我们基本上会在一个exception的同时收到多份exception通知邮件，数量可能是2可能是4或者是5，我的猜测是在这个异常向外抛的过程中，在多个地方截获处理并发出了通知邮件，这直接导致了我们监控异常邮件的工作量增加，同时统计异常数量不准确。(说明一下：异常邮件重复的原因仅是我的一种猜测，实际并不一定是重复处理异常引起的)
网友评论