服务器之家:专注于服务器技术及软件下载分享
分类导航

云服务器|WEB服务器|FTP服务器|邮件服务器|虚拟主机|服务器安全|DNS服务器|服务器知识|Nginx|IIS|Tomcat|

服务器之家 - 服务器技术 - 服务器知识 - 让错误处理重新由Web服务器接管

让错误处理重新由Web服务器接管

2019-12-24 22:20编程新说李新杰 服务器知识

读过的小伙伴应该能猜出来一些。因为SpringMVC开发的工程最终打成war包,然后扔到tomcat下面即可。而且SpringMVC和tomcat之间是通过Java Web的规范联系起来的,它们之间根本没有办法自由交互的。

其实web服务器是会处理错误的

让错误处理重新由Web服务器接管

在web.xml还是随处可见的年代时(确实有点老黄历了),下面的这些配置应该都不陌生。

根据错误代码处理错误,如下图01:

让错误处理重新由Web服务器接管

根据异常类型处理错误,如下图02:

让错误处理重新由Web服务器接管

不过我们更加熟悉的应该是SpringMVC的统一异常处理。如下图03:

让错误处理重新由Web服务器接管

看到@ControllerAdvice注解和@ExceptionHandler注解都应该很熟悉吧。

处理原理就是在捕获到业务Controller有异常抛出时,根据异常类型来这里找到对应的方法并执行。

可见,整个异常的处理过程都是在SpringMVC内部给搞定了,根本就没有涉及到web服务器,如tomcat。

那么问题来了,明明web服务器可以处理异常,为啥SpringMVC还要自己处理呢?

是不想呢,还是另有苦衷

读过的小伙伴应该能猜出来一些。因为SpringMVC开发的工程最终打成war包,然后扔到tomcat下面即可。

而且SpringMVC和tomcat之间是通过Java Web的规范联系起来的,它们之间根本没有办法自由交互的。

然而tomcat的错误处理需要在web.xml里面配置。严格来说,web.xml其实和SpringMVC关系不大。

特别是Spring全面进入Java和注解配置时代以后,web.xml逐渐被弱化,继而变得可有可无,直到最终完全消失。

所以(我猜测)SpringMVC可能不希望自己的用户到一个和自己关系不大的web.xml里面配置一些和业务相关的异常处理映射。

所以只好自己把异常处理消化掉。不劳tomcat大驾。因此才有了SpringMVC统一处理异常。

重新让web服务器来处理错误

当历史来到了SpringBoot的时代,SpringBoot翻身做主成了入口,web服务器竟然成了一个组件。

SpringBoot可以操作web服务器的API,通过编程的方式,对web服务器进行深度配置。

所以很多事情都变得容易起来,比如错误处理。

因为web.xml里的错误处理映射最终是注册到tomcat里面了,所以SpringBoot只要操作tomcat的API,使用编程的方式也来注册一些错误处理映射不就可以了嘛。

因为用户直接是和SpringBoot打交道的,所以SpringBoot需要抽象出一套错误处理注册机制,让用户来注册。

这样SpringBoot拿到用户注册的错误处理映射信息后,在生成web服务器(如tomcat)时,把这些映射信息添加到web服务器中即可。

SpringBoot注册错误处理映射的方案

先来看看错误处理映射是如何描述的,如下图04:

让错误处理重新由Web服务器接管

三个字段的含义是:

path是一个路径,它表示的是错误处理的url。

status是一个状态码,如404、500等。

exception是一个异常类型,如LoginFailedException。

一共有三种使用方式:

1)status + path,如404 + /404,表示如果遇到了404,就去执行/404这个url。

2)exception + path,如LoginFailedException + /loginfailed,表示如果遇到登陆失败异常,就去执行后面这个url

3)没有status和exception,只有path,这相当于通配符,匹配所有异常情况。

接下来就该考虑如何注册了,照例给个接口就行了,如下图0506:

让错误处理重新由Web服务器接管

让错误处理重新由Web服务器接管

Spring是以bean打天下的,所以SpringBoot给的方法当然也是和bean相关。

只要向容器中注册一个该接口类型的bean即可,如下图07:

让错误处理重新由Web服务器接管

这些信息会被收集到并存好,如下图08:

让错误处理重新由Web服务器接管

然后在创建web服务器时添加进去就行了,以tomcat为例,如下图09:

让错误处理重新由Web服务器接管

可以看到最终转换为tomcat的错误映射,如下图10:

让错误处理重新由Web服务器接管

这里的setLocation、setErrorCode、setExceptionType三个setter方法,就对应于web.xml里的、、这三个标签。

至此,错误处理已经被注册好了。

SpringBoot仍需协助处理错误

有一点需要明白,SpringMVC交给tomcat的只是错误处理映射的匹配工作,但有些真正的错误处理还是要自己做的。

所以整个过程是这样的,SpringMVC随意抛出异常,这个异常会被抛到tomcat里面,tomcat获取异常类型并根据注册的错误处理映射关系找到一个url,然后调用这个url。

那么请问这个url指向哪里呢?很大概率又回到了SpringMVC里面了,是不是很有意思,哈哈。

tomcat就像一面镜子,SpringMVC向它发射了一束光线,经过反射后又回来了。只不过发射的是一个异常,回来的是一个url。

这个url对应的是能够处理这个错误的一个Controller的方法。这样执行这个Controller方法就等于处理了异常。

这个Controller是一个能够处理错误的Controller,所以就叫ErrorController。如下图11:

让错误处理重新由Web服务器接管

其实它主要是一个Marker接口,也就起一个标志作用。

下面是真正用于处理错误的Controller,实现了刚刚的标志接口,如下图12:

让错误处理重新由Web服务器接管

@RequestMapping方法就是处理错误的,既可以返回JSON,也可以返回视图页面。

我们可以自己写一个错误处理类,然后继承这个类,添加自己的错误处理方法,最后使用@Controller注解重新注册即可。

可以把一个异常映射成和它名称一样的url路径,如把Exception映射为/Exception,如下图13:

让错误处理重新由Web服务器接管

这两个方法,一个返回html页面,一个返回一个JSON。

备注:异常类型和它映射的url之间的关系,可以按自己的需求去规划,统一规则即可。

处理错误时,自然要获得错误相关信息才行,这个接口可以满足,如下图14:

让错误处理重新由Web服务器接管

可以获得错误属性和抛出的异常对象。

可以看到接口的两个方法都有WebRequest这个参数,说明错误信息是从request中获取出来的。

同时也说明有些错误信息是有人专门放入request中的,是SpringBoot放的,还是web服务器放的?

其实都有,比如异常对象是SpringBoot放的,响应状态码是web服务器(按Java web规范)放的。

这也说明web服务器执行错误处理的url时用的是转发(forward)而非重定向(redirect),因为要保留request中的信息。

还剩最后一个,错误视图解析器,如下图15:

让错误处理重新由Web服务器接管

SpringBoot自己提供了默认的视图解析器实现,默认去classpath下面的error目录下寻找.html视图页面。

如下图16:

让错误处理重新由Web服务器接管

支持状态码到页面的映射,如404默认映射为/error/404.html,500默认映射为/error/500.html。

如果没有这么具体的页面,还支持系列映射,如404映射为/error/4xx.html,500映射为5xx.html。

当然,默认的一般都无法满足需求,我们可以继承这个默认的类,然后重写视图解析方法。

最后把这个类注册为bean即可,这样SpringBoot就会使用我们的类了。如下图17:

让错误处理重新由Web服务器接管

本文总结,重要

1)用户使用SpringBoot提供的错误处理映射机制注册状态码和异常的映射url信息。

2)这些映射信息最终会被注册进web服务器中,如tomcat。

3)SpringBoot把异常抛给web服务器,web服务器根据异常找到对应的url,并执行它。

4)流程再次回到SpringBoot中,进入错误处理Controller的方法中,执行错误处理方法。

5)如果需要解析视图的,使用错误视图解析器进行视图解析。否则就是直接返回JSON。

其中用户能参与的就三步,注册异常映射,扩展错误处理Controller,扩展错误视图解析器。

具体参与方式文章中都有,无非就是实现接口或继承某个类,然后注册为bean即可。

延伸 · 阅读

精彩推荐