如何判断你该不该抛出异常，以及抛出什么异常？

前情

最近在完成公司的一个上报征信数据的项目，项目不大，所以开发人员就我一个人，但是工期挺紧，所以每天都写代码写到起飞。项目到尾期后，有一些闲暇可以 review 一下代码。结果发现，我所有的参数校验都是在 controller 层完成的，service 层没有校验。思索了一下，发现一个有趣的之前我没有主要到的事情。

问题所在

controller 层校验后，可以通过返回字符串的形式，提示前端异常信息；service 校验后，需要返回 Exception 给上层。这会导致底层校验产生大量的自定义 Exception，但底层校验相比于顶层校验能辐射系统的更多部分，要想保持系统的健壮性，底层校验是必须的。那么由于底层校验导致上层代码涌现很多 try catch 怎么办？这些 try catch 还可能是级联的，一层一层抛出去。

先缕一缕异常的种类

service 层（这里举了 service 层的例子，实际上可以延伸到任何下层系统）可能抛出哪些异常？参数格式异常（比如要一段英文字符串，但是传入了数字字符串），业务逻辑异常（比如，数据重复或者找不到）。第一次想到这里的时候我脑袋里想的全是 checked 异常。但是灵光一闪，我发现 java 不是还有 unchecked 异常吗？

咱们先思索一下，明确 checked 异常和 unchecked 异常的区别。checked 异常表示，这个异常的出现是正常的，允许的，所以你需要在编程阶段考虑它。unchecked 异常表示这个异常是不正常的，它的出现表示你的代码存在逻辑错误，所以你需要在编程阶段保证它在运行时不发生。

现在我们有了两种异常定义的思路，一个是站在具体程序逻辑角度思考的（参数格式异常，业务逻辑异常），一个是站在编程语言角度思考的（checked 和 unchecked 异常）。

两种思考角度能否产生关联？

我们来看看 java 自己是怎么做的。

从 java 的一些库的设计上来说，通常参数的格式都作为一种协议，默认是大家都知道的，所以当格式错误的时候，程序抛出 unchecked 异常，你需要根据协议保证传入参数的正确性。java 有一个异常叫 IllegalArgumentException，它的出现表示“参数的前提条件不成立”，这个“前提条件”就是参数的协议。前提条件是通过文档等提前说明的，是一种你需要在编码阶段保证它在运行时不出现的异常。

java 有例子可以来说明 checked 异常，如 IOException，程序的 IO 必然和硬件打交道，而硬件并不像程序一样稳定，硬件可能掉电，可能因高温损坏，这些都是不可预期的，IOException 就可以用来表示与硬件交互过程中发生的不可预期错误。所以 File 类中出现 IOException，Apache 的CloseableHttpClient 类中出现 IOException。

啊哈！

有了 java 的例子，我们似乎可以更清晰的辨识 service 应该如何抛出异常了。在业务运行过程中可以出现的异常是checked异常，不可以或者说不应该出现的异常是unchecked异常。checked异常对于接收方来说，应该通过编码使程序可以应对这些异常；unchecked异常对于接收方来说，要么应该在编码阶段解决它，不让它在运行时发生（比如参数错误），要么只能认为系统发生了一些问题，可能需要人为介入来解决（此时你唯一能做的也许就是给自己发一个报警邮件）。

如此，大量的参数控制逻辑，可以通过抛出一个 unchecked 的 IllegalArgumentException 来实现（向 java 学习），我们也不必为它们自定义异常类，上层也不会被它们困扰。而另一些允许出现的异常，我们可以通过抛出自定义异常类的方式来表达错误发生了。由于剔除了参数校验的异常，这部分需要上层 try catch 的异常的数量就显得不是很可怕了，毕竟大多数业务逻辑可能根本不存在checked异常。