Java核心技术(一)：从FNTP的角度研读Exception的作用

type

status

date

slug

summary

🤔 标题党？请开始你的表演

关于为什么要写这篇文章

为什么要写这篇文章呢，主要是在工作中我们经常会遇到Exception，在工作中，正常的做法一般都是根据不同的业务属性去封装不同的Exception，而面对Exception这个核心问题，一方面我们务必要搞清楚Exception在Java这门面向对象的语言中所占据的地位与作用，另一方面我们更要去思考，Java的Exception异常实际用法是否必须跟随业务属性？再之，这种跟随业务属性的做法是否合乎情理？

关于讨论

由于作者水平有限，难免会有理解不到位的地方，欢迎各位指正；

📝所以，什么是Exception

James Gosling的看法

http://www.artima.com/intv/solid.html

上面这篇文章中记录了2003年的时候，詹姆斯高斯林对Java所引入的异常在程序设计上的看法。

Anders Hejlsberg的看法

http://www.artima.com/intv/csdes.html

Anders是C#的核心设计开发人员，创始人之一。这篇文章主要记载了他对程序设计的合理性的看法。

Sun Cheng Xin的看法

作为Java小生，当然没有资格去评论这两位扫地僧级人物的观点。两位大师的争论，堪称一绝，同时也让我收获甚多。

1、对于面向对象

我个人而言，Java之所以引入Exception异常，首先他是完全符合面向对象的设计理念的，什么谓之面向对象，我的理解就是在数据维度对数据资源进行抽象化的同时将操作数据的方式方法组合在一起的思想，就是面向对象，面向对象主要解决在空间层面，对对象属性定义封装，在时间层面，显式地去展现对对象的属性操作所产生的的影响。

2、对于Checked Exceptions

Checked Exceptions 就是编程语言所提供的系统级保证，不能说没有Checked Exceptions机制，程序就不能拥有优良的性能，Checked Exceptions从语言结构层面来看，更是在时间层面对对象的属性操作所产生的的影响的一种完美的抽象，可能难以理解，我举个简单的例子：A是一个对象，A有若干属性，xyz，面向对象的编程思想在设计构建A的时候，就会连同可能会出现的对A属性操作的动作及其产生的影响的方式方法一并融合在一起，而正是这种可能出现的对属性操作的动作以及其影响间接产生了Java对意料之外的情景抽象，这个抽象的结果就是异常。当然，这种理解难免有掺杂业务的嫌疑，但实际上是否是我描述的这样，我们可以接着往后看。

3、对于Exception的使用，我敢说绝大多数人都理解不对

从我看了他们的研讨之后，我也在反思，我技术不深，所以没有资格去评价扫地僧们的观点，但是我知道绝大多数的Java程序员根本就没有领悟“Exception”的真正用处。他们就是把Exception当做异常来理解，没有明白Exception实际上代表了一个UseCase中的异常流的处理。

在使用UseCase（用例）来描述一个场景的时候，有一个主事件流和n个异常流。异常流可能发生在主事件流的过程，而try语句里面实现的是主事件流，而catch里面实现的是异常流，在这里Exception不代表程序出现了异常或者错误，Exception只是面向对象化的业务逻辑控制方法。如果没有明白这一点，那么我认为并没有真正明白应该怎么使用Java来正确的编程。

在初学Java的业务实现过程中，我会自定义大量的Exception类，所有这些Exception类都不意味着程序出现了异常或者错误，只是代表非主事件流的发生的，用来进行那些分支流程的流程控制的。例如你往权限系统中增加一个用户，应该定义1个异常类，UserExistedException，抛出这个异常不代表你插入动作失败，只说明你碰到一个分支流程，留待后面的catch中来处理这个分支流程。传统的程序员会写一个if else来处理，而一个合格的OOP程序员应该有意识的使用try catch 方式来区分主事件流和n个分支流程的处理，通过try catch，而不是if else来从代码上把不同的事件流隔离开来进行分别的代码撰写。而在传统业务开发过程中，实际上则是通过封装一个RuntimeException之后，通过Spring所提供的的异常封装机制，定义一系列的异常码来处理，在软件内部来说，通过枚举异常编码的形式代替Exception类，不得不承认这种做法一方面是对Exception的又一次抽象化，但另一方面这完全不符合OOP的正常设计思想…(未完待续)

💡

有关异常使用的问题，欢迎您在底部评论区留言，一起交流~