概述
从提升产品质量的角度出发,任何异常都应该被优雅的处理。所谓“优雅”一词即是实现逻辑清晰以减少BUG率,提高开发效率,提升用户体验的一种范式。那如何优雅的处理异常呢?以JAVA程序为例,从处理的角度讲通常可分为可预见的、非法的、其他的这三类。因为声明式异常本身是一种编码强制性处理的异常,因此不做赘述,下面着重讲了运行时的异常处理范式。
声明式异常的处理
声明式异常在编译前就要求我们必须处理,比如使用IO流相关代码我们要处理文件找不到的情况,网络意外中断的情况。我们可以使用try语句捕获到该异常然后给用户一个友好的提示,或者进行补偿逻辑。最终的目的是把这些确定存在的异常情况优雅的处理,提升产品质量。
运行时异常的处理
运行时异常编译器并没有强制我们处理,运行时异常设计的初衷,是因为我们无法预知程序的所有异常,比如某方法要求必须输入正确的身份证才可获得正确信息,可是用户或者黑客偏偏输入错误的身份证信息,由此会触发找不到该信息的异常。再者运行时异常种类繁多从开发效率的角度我们无法照顾到所有细节。但我们可以通过以下提供的方法来将运行时异常分为三类,这样我们就能有效的处理运行时的所有异常来提高产品的质量。在软件产品质量管理过程中,为了便于表述这种异常处理的范式,暂且将这种异常处理的范式命名为异常处理三型范式。
一型异常-可预见输入型异常
可预见输入型异常是业务逻辑中可以预期到的异常,由我们主动判断并抛出,比如常见的数据准确性校验;用户数据缺失某一环节的数据等;此类异常是业务中可以预见的异常,但从软件设计的角度来讲:此类异常产生的原因是因为软件初期考虑开发效率及成本且对用户体验要求不高,此类异常作为客户端的提示信息弹出。
处理方式:此类异常不在控制台打印,但应该在软件迭代的过程中逐步通过前端人性的化的交互避免用户输入这类数据,从而将异常抛出点升级为二型异常。因此提升了用户体验效果。
二型异常-非法输入型异常
非法输入型异常是预期内不可能由用户正常输入的异常,此类异常在排除BUG的原因后就只剩下黑客攻击了,所以最好的做法将一切可追溯的日志信息报送到预警系统,做相应的防护,报送后就没必要在控制台或者日志中记录了,因为保持控制台清爽有助于运维工程师、程序员发现程序漏洞。
X型异常-其他异常
其他异常是没在预期分类下的所有运行时异常,此类异常表示系统有BUG,没什么好说的,应该必须消灭掉。
以JAVA语言为例
一型异常我们可以自行定义异常类继承自RuntimeException,命名为:BusinessException;
二型异常使用IllegalArgumentException(也是继承自RuntimeException)。
三型异常是直接捕获RuntimeException进行处理。
异常处理示例
假设我们有一系列的自动化运营的棋牌室房间,打开棋牌室的门的条件必须得年满18岁且实名认证;用户操作流程是登陆后扫码,因此我们需要设计的一个接口传入用户信息来执行开门的命令,暂且将该方法命名为openDoor(user);如果传入的用户合法正常开门,非法则抛出一个异常,大家来比较下面2种架构的用户体验。
架构一
不管用户符合不符合条件都可以调用该方法并获得提示:该方法内部抛出throw new BusinessException("未实名认证"),用户得到提示后去进行实名认证。
架构二
用户扫码后发现用户不是实名认证的先去引导用户实名认证,之后再调openDoor(user)。如果该方法内部抛出:throw new IllegalArgumentException("未实名认证"),因此我们可以推断得知:如果抛出了【未实名认证】的异常一定是有黑客试图破解门来获得免费进入棋牌室的资源。
总结
第二种架构是明显比第一种架构的软件要人性的多健壮的多,然而在软件工程开发实践中,受限于开发成本及架构师的水平,第一种架构是非常常见的,因此BusinessExCeption是一个非常有必要的一个异常。然而在软件迭代过程中,BusinessException也是一个应该被逐步消灭的异常。