推荐关注
› Meteor
› JSLint - a JavaScript code quality tool
› jsFiddle
› D3.js
› WebStorm
推荐书目
› JavaScript 权威指南第 5 版
› Closure: The Definitive Guide
› Closure: The Definitive Guide
这是一个创建于 946 天前的主题，其中的信息可能已经有所发展或是发生改变。
前端用 axios 发的请求如果参数不全后端返回 400 ，但是我在 axios 里 then 后 catch 了，能够 catch 到 status 400 ，但是 F12 里面还是有红色的，不好看
xhr.js?b50d:210 POST http://localhost:8080/api/comment/ 400 (Bad Request)
即使加了拦截器也没起作用，这个能被拦到到吗？
当然在前端做参数校验有错就不提交，是可以避免后端返回 400 ，就想问下这个能避免吗
 |
1
chendy 2022-04-07 16:23:31 +08:00
浏览器行为，跟你处不处理没有关系
另外这有啥不好看的，用户不会看，开发看不到了不方便查问题 |
 |
2
EastLord 2022-04-07 16:25:53 +08:00
http status 400 就应该是红色吧
|
 |
3
hronro 2022-04-07 16:31:08 +08:00  7
「 F12 里面还是有红色的，不好看」
请原谅我笑了 |
 |
4
rekulas 2022-04-07 16:41:37 +08:00
看看 try catch 能否 handle
|
 |
5
wangtian2020 2022-04-07 16:46:43 +08:00
现代后端不是都请求返回 200 ，然后 400 、500 状态码 code ，错误说明 msg ，单独存在返回值里吗。单返回个 400 谁懂什么错
|
 |
6
jamosLi 2022-04-07 16:51:39 +08:00
这就真是谜之操作了
|
 |
7
persona5 2022-04-07 16:58:13 +08:00
不是故意抬 1L 的杠，我们还真遇到过这种情况。
给国企内部部署的服务，反馈中有客户截图 devtools console 界面，说有红色的报错让我们处理。 最后领导说不用管。 |
 |
9
HeStudy 2022-04-07 17:09:00 +08:00
重写 console.err 试试，应该可以去掉。
|
 |
10
elboble OP @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 接口写的，但是的确是不好处理，比方说这个错误原因，就不好取出来。 |
 |
12
learnshare 2022-04-07 17:17:27 +08:00
觉得不好看的话，给线上禁用开发者工具
报错日志通过 Sentry 收集 |
 |
13
akaxiaok339 2022-04-07 17:43:55 +08:00
部一个 nginx 处理，报产出 /doge
|
 |
15
dengshen 2022-04-07 18:50:55 +08:00 via iPhone
那是 http 的状态码。不想爆红很简单。后端无脑返回 200 。前端在返回体中自己根据业务 code 判断正常还是错误
|
|
16
rekulas 2022-04-07 18:56:17 +08:00
可能如上面所说浏览器默认行为不好 handle ，只能像楼上说的 code 放 body 里判断
或者直接无脑请求完毕 console.clear()。。。 |
 |
17
netnr 2022-04-07 19:16:01 +08:00 via Android
这个问题要结合 后端返回 code 是在 body 还是 http 状态码，在引用一张图片(状态码 200 body 里面 404 的痛苦面具)
|
 |
18
Jarvis666 2022-04-07 19:19:37 +08:00
自定义错误码，后端全部返回 200
|
 |
19
des 2022-04-07 19:25:13 +08:00 via iPhone
直接反调试，打开 F12 就崩溃
|
 |
20
libook 2022-04-08 10:29:44 +08:00
在 HTTP 标准中，400 代表服务端无法理解客户端的请求，按标准来说，所有业务当场景中，这一定是不应该出现的，正式客户端的任何请求都应该是在预期范围中的，有错误也应该是业务上预期存在的可能性，即业务上预期的错误应该返回 2xx 状态码，并在返回载荷中说明是什么错误。
除非项目自己将 HTTP 状态码进行了重新定义，比如像 REST 风格中，将状态码和业务捆绑到一起，此时 400 不光代表 HTTP 协议上的错误，也同时代表业务上预期存在的错误。 所以看你们使用状态码是遵循 HTTP 的标准定义，还是有一套自定义；如果是标准定义，那么返回 400 就不是好不好看的问题，而是程序确实存在问题；如果有自己一套定义，就得看当前情况下返回 400 是否合理，合理的话就没必要处理。 另一方面，浏览器通常是严格遵循 HTTP 标准的来设计的，也默认网站开发者是遵循 HTTP 标准来设计网站的，那么不管你们项目如何自定义状态码，浏览器一定认为 400 是个问题，所以会在开发者工具中给予提示。 就好比是消防传感器（感烟）会对室内吸烟行为有反应，吸烟的人知道现在没发生火灾，但消防标准规定传感器就应该在探测到任何烟雾的情况下通知报警。 浏览器的行为是浏览器开发者在代码里定义死的，除非你获得浏览器代码自己魔改，并给用户提供魔改版的浏览器安装包，否则是没法改变浏览器的行为的。 开发者工具是提供给浏览器用户的工具，而不是提供给网站开发者的工具（虽然有时候两者是同一个人），网页上的代码无权控制开发者工具的行为。 |
 |
21
Rache1 2022-04-08 18:04:04 +08:00
我在项目中就加了个环境变量 HTTP_RESPONSE_ALWAYS_RETURN_200 ，如果为 1 ，就所有 response 都返回 200 😂，业务响应 code 的前三位还是是对应 HTTP CODE 的。
|
|
22
elboble OP @libook 嗯，restful 不是太灵活，一般还是按楼上说的，统一 post ，统一返回 200 ，然后在返回包里面自定义状态码，比较可控一点。
|
 |
23
IvanLi127 2022-04-08 23:46:26 +08:00 via Android
不把异常当异常的人，和用 HTTP status 永远 200 的人，原来是同一波人！
|
Select Language