前言
在日常研发流程中，我们通常会自己新建一些BusinessRuntimeException通过throw new BusinessRuntimeException的形式来抛出业务代码，并通过全局的ExceptionHandler来控制返回。 这样做的好处是我们可以在最外层控制我们抛出的异常不会是未经过加工的异常。但在code review过程中，经常发现有些同学滥用自定义的Exception导致代码整体的可读性很差。 在这里提供一下个人对这个问题的处理经验，仅供参考：
先熟悉Java常见Exception
在你自定义Exception之前，你应该熟悉Java语言中自带的一些Exception。 这些类常存在于Java.Lang的包中。
Checked Exception
Checked Exception即你需要在代码中显式处理的Exception。 一般Checked Exception通常是JVM不能预测的Exception， 例如IOException，需要和底层操作系统接口交互，并且有可能会交互失败， 这种情况就会需要你在代码中显式考虑这种失败场景。
在业务代码中如果碰到底层调用的方法会抛出Exception，优先考虑的处理方法是通过Try catch包住并处理掉， 不要再往外层抛出。 原因：越靠近Checked Exception的越知道如何处理。
RuntimeException
在业务代码中，能用Java自带的RuntimeException的，优先采用RuntimeException， 并在Error Handler中对这些常见的Runtime Exception进行封装。 例如，某个类的某个字段不能为空，当传入空值时就应该抛出NullPointerException, 并且在最外层对NullPointerException进行映射，返回映射后的ErrorCode。 可以参考：极光分享 - ErrorCode 定义 - 极光文档 (jiguang.cn)
当预定义RuntimeException不能满足需求的时候可以自行创建Exception，但应保证抽象。 Exception是抽象，具体到业务场景的应该用ErrorMessage区分， 这样做的好处是不需要维护太大的ErrorCode列表。 当你底层服务往上层服务抛异常的时候，较少的ErrorCode比较方便外部处理。
