在一个软件系统的运行过程中或多或少都会因为一些问题发生跳出正常业务流程的情况。通常这些导致跳出正常执行流程的问题被我们称为异常,而对异常的处理流程我们称为异常流程。
然而,经过一些年的编码实践后我们会发现,这些导致系统跳出正常流程的问题是多种多样的。
- 有些是可以被预见有些则不可预见,可以预见的可以根据问题产生的特定条件和对系统的影响设计相应的应对方案,不可预见的则只能通过捕获记录运行时上下文信息再来分析具体原因寻找解决方案。
- 处理流程有些可以直接将问题描述反馈给用户,有些则只能由系统记录或尝试其它执行流程。
面对如此复杂的问题域我们仅以一个单一的异常概念对其进行建模设计,是否可以应对所有甚至大多数场景呢?对于较小型的系统应该问题不大,如果是中大型的系统估计就会比较难了。所以,在稍微上点规模的系统中我们时常就会看到非常多的异常类型定义。在我们实际的系统设计和研发过程中,可以如何去建立起一个合理、优雅的异常管理体系呢?以下分享一些我个人的思考和理解。
概念探讨
在大多数编程语言中对于异常所提供的都是 try catch 的异常捕获处理机制。语言提供的只是一种处理工具,个人认为在实际系统设计过程中我们应该根据自己的业务和系统的特点建立自己的异常体系,然后再结合语言所提供的语法特性加以实现。
首先最基础的,我们可以把所有可能导致业务跳出正常流程的问题划分为两大类概念:错误和异常。(使用过 Golang 的人都知道在 Golang 中正是以这两个概念来提供对异常的处理机制。)以下是我对这两个概念的理解:
错误
错误是由于外部输入导致内部流程无法按照设计正常执行的情况。在设计和实现系统时我们已经识别到错误可能会不可避免的发生,所以在设计时就已经为这些识别到的错误提供了一些发生后系统相应的处理流程