从 URL 获取即使在捕获之后也会在控制台中显示错误？

Question

假设，我有这个函数提供了错误的“uri”字符串来获取：

function imgChanger(uri) {
    fetch('uri', { mode: 'cors' })//WRONG 'uri' to demonstrate that catch doesn't prevent console's red error
        .then(function (response) {
            if (!response.ok) {
                throw new Error(response.statusText);
            }
            return response.json();
        }).then(function (response) {
            img.src = response.data.images.original.url;
        }).catch((err)=>{
            console.log(err);
        });
}

尽管处理了错误，我还是可以在控制台中看到 404 消息：

我对此有两个问题：尽管捕获了它，为什么还是会显示它以及我该如何处理它？

Answer 1

恐怕你在这里无能为力。有一个问题 124534：提供一种在大约 10（！）年前在 Chromium 中打开的控制台中不显示 404 XHR 错误的方法：

Chromium 始终在 Javascript 控制台中将 HTTP 404 显示为错误。除了在开发人员可能不想要的时候将线路噪音强加给他们（404 可以在“网络”选项卡中轻松发现）之外，我认为这实际上违背了 HTTP 的精神。例如，如果您有电话目录查找，并且您 GET http://myHost/directory/numbers/12345678

...如果该号码不在目录中，服务器应响应 404。在我看来，这甚至确实是一个“错误”——这只是信息。为什么 Chromium 应该在控制台中将其显示为错误？

正如您所看到的，它仍然是开放的（并且本质上被视为“设计使然”）。这是另一个有说服力的引言：

8 年过去了，我仍然无法控制客户如何响应请求。我们的内部 API 已更改为始终以 200 响应，并使用自定义状态字段来正确过滤实际错误和根本不存在的错误。

我们必须放弃 REST 来实际使用语义状态，这是令人痛苦的白痴。

但庆幸吧！2021 年似乎会进行讨论，所以希望我们最终能让事情取得进展。现在，不幸的是，事情并不那么容易：

人们似乎普遍认为最好从控制台中删除这些错误消息。但当前许多 DevTools 用户也很可能在其工作流程中依赖这些错误消息。我们还没有找到调和这两方面的方法。

现在是强制性的xkcd 漫画：