Reporter@ - Thanks for filing the issue...!!

Could you please provide a sample URL to test the issue from TE-end.
This will help us in triaging the issue further.

Thanks...!!

Thanks for the report.  Making network requests can produce console Network errors (e.g. 404 <url> not found), sometimes followed by a JS errors (e.g. TypeError when calling fetch() offline).  To better understand your case, could you please provide an example of how your requests are made and 'gracefully handled'?

When a request generates a network error+JS error, the JS error can be caught, but the only way to hide the network error is with the 'Hide network' setting.  I've attached a screenshot of these cases.  If I understand correctly, you're requesting that the first call should not show the 'GET' error at all?

Deleted: handledUnhandledNetworkError.png 99 KB

	handledUnhandledNetworkError.png 99 KB View Download

> If I understand correctly, you're requesting that the first call should not show the 'GET' error at all?

Yes. Same way you don't get an error logged to the console if there's some js error and you catch it.

You can now avoid logging to the console using 'Hide network' setting. But the red badge in main toolbar is still shown. I think that:
- If you choose not to log, badge shouldn't be shown either.
- That should be the default behaviour.

Of course this would only apply to catched network errors. Uncatched ones would always go to the console/badge.

But there's more:

Your samples deal with fetch's "catch" branch.
My main problem is with fetch's "then" branch.
Say you issue a request, and you get a 403 in response.
This doesn't make fetch generate an error and enter the catch branch.
This goes through the normal then branch.
It's just that response.ok is false.
But the "error" is logged to the console, amd even if I use the 'Hide network' setting, it still goes to the badge.
I find it inconsistent that something that is not even an error for the fetch function, it's marked as such in the console panel.
That's my main point. 403 and other non-200 responses are not considered errors by the fetch function nor by my application. They are normal, application level responses, handled in a then(response => {...}) branch without errors.
Why should they marked as errors in the console?

An example of what I last stated above. Type the following in console:

fetch("https://httpstat.us/403").then(response => {
    if (response.ok)
        return "yes!";
    if (response.status == 403)
        console.log("403 handled gracefully");
});

IMHO, this should not show any error whatsoever in console.

Thanks for the example, I see the use case more clearly.  As you mention, the 'Hide network' checkbox hides the messages you don't want, and although it is not on by default, the setting will persist even if you close and reopen DevTools.  Maybe there are enough other developers who want to see it on by default, but I think we need to see more feedback / stars to decide to change this.

The red error badges in the top-right corner of DevTools are there to count errors received by DevTools.  Since 'Hide network' is considered a filtering setting, the count is not affected because errors are still received by DevTools.

I understand what you mean. about red badges showing all errors received by devtools.
That's precisely what I'm challenging. Sorry for not having expressed it better before.

My line of reasoning is:

If receiving a 403 is not considered an error by the calling function (fetch), why should devtools mark it as such?
Well, ok, devtools is not signaling a javascript error in fetch, but a network "error" previous to that.
But then, if I choose "Hide network errors" setting, why does devtools insist on showing the badge?

Current situation makes it impossible, for example, coding against a REST API which uses non-200 status codes without having your console full of red, even if there are no problems and everything is working fine.
It breaks the property "if there's something red, there's something I have to fix', which I'm sure many developers have been used to.

Possible solutions could be:
1) Make 'Hide network errors' setting hide also badge, not only console message.
2) Add another setting to choose what devtools consider network errors. Options could be:
  * all non-200
  * only 500
  * a list of status codes to be considered errors

This request has been open for awhile, and with our current priorities, it does not seem like it will be fixed soon.  Archiving this for now, sorry for the inconvenience.

DevTools makes the assumption that non-200 network responses are errors, which is not always a valid assumption for all use cases.  Your proposals to address this are neat, but we don't currently have plans to address this bug.

> Make 'Hide network errors' setting hide also badge, not only console message.
This would work in your case, but I'm concerned that it breaks the workflow where people use 'Hide network errors' as a filtering checkbox.

> Add another setting to choose what devtools consider network errors
This addresses the problem, but requires much work to bring value.