在系统中，异常被分为了两种，一种是已知异常，一种是未知异常。
已知异常在框架中被封装为 cn.vte.framework.common.http.InnerExp，一般为业务异常，可以在任何接口访问范围内的代码内抛出。
InnerExp 作用
InnerExp 是为了能够灵活返回信息到前端，当方法的调用过多时或者逻辑嵌套过深，在满足条件时，不用一层一层返回，直接抛出异常即可把信息返回。
配合 GlobalMvcExceptionHandler 使用，该类拦截了所有的 mvc http 接口异常，任何异常都会被处理成 RequestResult 结构。
InnerExp 特别的是，它会携带两种信息，一个是 RequestResult 还有一个是 Exception。这让 InnerExp 有更加灵活的功能。
InnerExp 携带 RequestResult 能够让返回的结果更加丰富，开发人员可以自定义 RequestResult 的内容，甚至与返回正常的结果。
比如当你使用递归调用时，满足条件收集到了足够的信息时，抛出一个异常直接把结果返回，所以异常的使用不完全是为了通知程序异常了，灵活使用也能够处理正常的业务。
InnerExp 携带 Exception 时，GlobalMvcExceptionHandler 会判断 cause 是否为空，如果不为空就直接打印堆栈信息，帮助排查问题，在业务代码遇见异常，并且不想处理时，直接交给最上层去做，有些时候会更加方便。
总结一下 InnerExp 的功能：
- 快速抛出异常，将信息返回给前台，函数嵌套的情况下不用层层传递信息，并且能够携带真实异常，顶层打印堆栈信息。
- 快速返回业务信息，同样不用层层传递。
- 继承
Supplier接口，在流式处理中更加方便抛出异常。 - 利用
ifThr传入条件判断是否应该抛出异常。
处理其它异常
在已知异常之外，其它异常情况的处理就相对棘手一些，出现什么种类的异常是完全未知的。
你只能在发生某些异常的时候处理。
可能你会问，为什么不直接都当成一种情况处理呢？只要发生异常一律告知内部异常。
这样处理虽然简单，但是很多异常实际上不是后端逻辑错误引擎的，更多的是数据校验方面的引起的，一般是由于前段发送数据不符合后端的要求。
此时，你就要处理这种用异常，把他们整理成前端开发人员，甚至是用户能够看懂的异常。
下面是框架中，所遇见过的一些异常类型处理。
1 ServiceUnavailable
由于 feign 调用不到的产生的异常。
框架会返回”后台服务未启动”的提醒。
2 HttpMessageNotReadableException
由于前端传入的 json 数据，无法正常序列化为 java 对象产生的异常。
此异常处理的情况较为复杂，因为处理异常本身不重要，更重要的是处理它携带的 cause。
框架中处理了四种 cause ：
InvalidFormatExceptionMissingKotlinParameterExceptionJsonMappingException- 其它异常
1、2、3，实际上都为 jackson 所抛出的异常。
此处，又是 jackson 的一大亮点，那就是你能够通过这些异常，来捕捉到 json 序列化的错误位置。
因为这些异常，都携带有 getPath() 方法，能够找到嵌套的 json 错误路径，于是框架中利用了这一点，来获取 jackson 序列化错误的详细字段信息
fun List.toPath(): String {
val sb = StringBuilder()
this.mapIndexed { index, reference ->
sb.append(
if (index == 0 || reference.fieldName == null) {
reference.fieldName ?: "[${reference.index}]"
} else {
".${reference.fieldName}"
}
)
}
return sb.toString()
} 举个例子，下面的这段代码，将会输出，a.type，来告知前端，a 对象下的 type 缺失。
data class A(val name: String, val type: String)
data class B(val name: String, val a: A)
val test = JacksonObject().put("name", "b").put("a", JacksonObject().put("name", "a"))
try {
test.convert()
} catch (e: IllegalArgumentException) {
val cause = e.cause
if (cause is MissingKotlinParameterException) {
println(cause.path.toPath())
}
}除了上面的处理 JsonMappingException 还要单独拿出来处理，下面这段代码说明了处理的思路
is JsonMappingException -> {
val subCause = cause.cause
if (subCause is InnerExp) {
// 发生于 class init 抛出异常
subCause.result
} else if (subCause is DateTimeParseException) {
RequestResult.error("""字段"{}"时间值错误:"{}"""", cause.path.toPath(), subCause.parsedString)
} else {
log.warn("{}", request.requestURI, exception)
RequestResult.error("""字段"{}"值错误:"{}"""", cause.path.toPath())
}
}这样处理异常的方式，很明显能够大大减少排查问题的难度。
3 NoHandlerFoundException
当地址找不到产生的异常，如果不处理，将返回 404。
4 MethodArgumentNotValidException
当 spring boot valid 校验失败产生的异常。
框架中，将会获取到校验失败的信息，然后以 RequestResult 的方式返回，减少前端的处理工作。
如果不处理，前端是无法获取到错误的详细信息的，那么校验所能产生的作用就会大打折扣。
本文参与了思否技术征文，欢迎正在阅读的你也加入。