chrome F12 里的 400 报错怎么能拦截到

2022-04-07 16:06:50 +08:00
 elboble

前端用 axios 发的请求如果参数不全后端返回 400 ,但是我在 axios 里 then 后 catch 了,能够 catch 到 status 400 ,但是 F12 里面还是有红色的,不好看

xhr.js?b50d:210          POST http://localhost:8080/api/comment/ 400 (Bad Request)

即使加了拦截器也没起作用,这个能被拦到到吗?

当然在前端做参数校验有错就不提交,是可以避免后端返回 400 ,就想问下这个能避免吗

3087 次点击
所在节点    JavaScript
23 条回复
chendy
2022-04-07 16:23:31 +08:00
浏览器行为,跟你处不处理没有关系
另外这有啥不好看的,用户不会看,开发看不到了不方便查问题
EastLord
2022-04-07 16:25:53 +08:00
http status 400 就应该是红色吧
hronro
2022-04-07 16:31:08 +08:00
「 F12 里面还是有红色的,不好看」

请原谅我笑了
rekulas
2022-04-07 16:41:37 +08:00
看看 try catch 能否 handle
wangtian2020
2022-04-07 16:46:43 +08:00
现代后端不是都请求返回 200 ,然后 400 、500 状态码 code ,错误说明 msg ,单独存在返回值里吗。单返回个 400 谁懂什么错
jamosLi
2022-04-07 16:51:39 +08:00
这就真是谜之操作了
persona5
2022-04-07 16:58:13 +08:00
不是故意抬 1L 的杠,我们还真遇到过这种情况。
给国企内部部署的服务,反馈中有客户截图 devtools console 界面,说有红色的报错让我们处理。
最后领导说不用管。
bclerdx
2022-04-07 17:05:20 +08:00
@persona5 为啥不用管?
HeStudy
2022-04-07 17:09:00 +08:00
重写 console.err 试试,应该可以去掉。
elboble
2022-04-07 17:10:50 +08:00
@wangtian2020 后端是 DRF 返回的
```
{data: {…}, status: 400, statusText: 'Bad Request', headers: {…}, config: {…}, …}
config: {transitional: {…}, transformRequest: Array(1), transformResponse: Array(1), timeout: 0, adapter: ƒ, …}
data:
content: Array(1)
0: "This field may not be blank."
length: 1
```
虽然是按 restful 接口写的,但是的确是不好处理,比方说这个错误原因,就不好取出来。
elboble
2022-04-07 17:11:42 +08:00
@rekulas 异步的好像 try catch 不住
learnshare
2022-04-07 17:17:27 +08:00
觉得不好看的话,给线上禁用开发者工具
报错日志通过 Sentry 收集
akaxiaok339
2022-04-07 17:43:55 +08:00
部一个 nginx 处理,报产出 /doge
chendy
2022-04-07 18:45:47 +08:00
@persona5 为啥不管呢,前端有业务逻辑可以接受报错的情况?
dengshen
2022-04-07 18:50:55 +08:00
那是 http 的状态码。不想爆红很简单。后端无脑返回 200 。前端在返回体中自己根据业务 code 判断正常还是错误
rekulas
2022-04-07 18:56:17 +08:00
可能如上面所说浏览器默认行为不好 handle ,只能像楼上说的 code 放 body 里判断

或者直接无脑请求完毕 console.clear()。。。
netnr
2022-04-07 19:16:01 +08:00
这个问题要结合 后端返回 code 是在 body 还是 http 状态码,在引用一张图片(状态码 200 body 里面 404 的痛苦面具)
Jarvis666
2022-04-07 19:19:37 +08:00
自定义错误码,后端全部返回 200
des
2022-04-07 19:25:13 +08:00
直接反调试,打开 F12 就崩溃
libook
2022-04-08 10:29:44 +08:00
在 HTTP 标准中,400 代表服务端无法理解客户端的请求,按标准来说,所有业务当场景中,这一定是不应该出现的,正式客户端的任何请求都应该是在预期范围中的,有错误也应该是业务上预期存在的可能性,即业务上预期的错误应该返回 2xx 状态码,并在返回载荷中说明是什么错误。

除非项目自己将 HTTP 状态码进行了重新定义,比如像 REST 风格中,将状态码和业务捆绑到一起,此时 400 不光代表 HTTP 协议上的错误,也同时代表业务上预期存在的错误。

所以看你们使用状态码是遵循 HTTP 的标准定义,还是有一套自定义;如果是标准定义,那么返回 400 就不是好不好看的问题,而是程序确实存在问题;如果有自己一套定义,就得看当前情况下返回 400 是否合理,合理的话就没必要处理。

另一方面,浏览器通常是严格遵循 HTTP 标准的来设计的,也默认网站开发者是遵循 HTTP 标准来设计网站的,那么不管你们项目如何自定义状态码,浏览器一定认为 400 是个问题,所以会在开发者工具中给予提示。

就好比是消防传感器(感烟)会对室内吸烟行为有反应,吸烟的人知道现在没发生火灾,但消防标准规定传感器就应该在探测到任何烟雾的情况下通知报警。

浏览器的行为是浏览器开发者在代码里定义死的,除非你获得浏览器代码自己魔改,并给用户提供魔改版的浏览器安装包,否则是没法改变浏览器的行为的。
开发者工具是提供给浏览器用户的工具,而不是提供给网站开发者的工具(虽然有时候两者是同一个人),网页上的代码无权控制开发者工具的行为。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/845503

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX