A way to stop WebSocket errors to show up in browser's console

Question

So the problem is when I try to initiate a new WebSocket to a remote host, sometimes the browser's console prints a red error message and complains about a refused connection, here is the message:

Error in connection establishment: net::ERR_CONNECTION_REFUSED

Having an error is fine since the remote host might be not responding sometimes, but the fact that I cannot handle this error message is very annoying.

Is there any way to either handle this error message or check whether the remote host accepts the WebSocket connection before initializing one in my JavaScript code??

Q: Is the error message printed out in the developer tools console, or somewhere an end user is likely to see it? — paulsm4, Oct 12 '19 at 20:51
OK - well that's *EXPECTED*. It's a Good Thing that the debugger shows you network level exceptions. It's also a Good Thing that it shows "error" exceptions in red. Why would you want to gag this functionality? Especially since the end-user wouldn't see it? The main point is - you *CAN* handle exceptions in your code, for example `socket.onerror`. — paulsm4, Oct 13 '19 at 15:46
I see your point but, still, there should be a way to handle this error to not be printed out in the console. It is odd that there is no way to handle this error message. Either `try-catch`, `EventListener`, or `onerror()` solutions work for this problem. — Chavoosh, Oct 14 '19 at 03:11
The exception *CAN* be "handled". You're talking about something *different*: a debugger feature called "first-chance exception". See the updates to my response below. — paulsm4, Oct 14 '19 at 05:55
I have the same requirement. Although it may be good to show errors in the console, they shouldn't be shown if they are inside a catch statement. Websockets can be used with a polling technique for connecting local applications, and the console window will be polluted with failed attempts. — Jaime, Jun 22 '20 at 02:55

paulsm4 · Accepted Answer · 2019-10-14T03:52:35.100

Several possibilities come to mind:

Add a WebSocket.onerror error handler
```
myWebSocket.onerror = myEventHandler;
```

Wrap your "connect" in a try/catch block

try {
   const connection = new WebSocket(myUrl);
   ...
}
catch(error) {
   console.error(error);
}

Structure your code such that your I/O is event driven:

https://developer.mozilla.org/en-US/docs/Web/API/WebSocket#Examples

    // Create WebSocket connection.
    const socket = new WebSocket('ws://localhost:8080');

    // Connection opened
    socket.addEventListener('open', function (event) {
        socket.send('Hello Server!');
    });

    // Listen for messages
    socket.addEventListener('message', function (event) {
       console.log('Message from server ', event.data);
    });

    // Handle errors
    socket.addEventListener('error', function (event) {
       console.log('WebSocket error observed:', event);
    });

ADDENDUM:

The above methods allow you to completely handle a websockets exception.
Regardless of whether the exception is handled or not, the Chrome debugger will tell you if an exception has occurred. This is a Good Thing. It's called a "First-Chance Exception":

https://learn.microsoft.com/en-us/security-risk-detection/concepts/first-chance-exception

.. it is known a “first chance” exception – the debugger is given the first chance of inspecting the exception prior to the application handling it (or not).

In Microsoft's Visual Studio debugger, there's a little checkbox you can use to "gag" first chance exceptions. I'm not aware of any similar "checkbox" in Chrome debugger.
POSSIBLE SUGGESTIONS:
- Chrome debugger has a "filter". EXAMPLE FILTER REGEX: ^((?!ERR_CONNECTION_REFUSED).)*$
- This link suggests you might be able to use the filter to "Hide Network Messages" (I haven't tried it myself). See also this link.

Thanks for the reply. However, none of the approaches work. Still, a big red error message appears in the console. — Chavoosh, Oct 12 '19 at 17:09
This post doesn't resolve the question (not to show the web socket error message in the console). Other catched errors are not shown in the console. — Jaime, Jun 22 '20 at 02:53
+1 to noting that this is not a solution. But worse, saying that it is a "Good Thing" (capitalized for good measure) is plain silly. ***Catching*** errors is a Good Thing. Not being able to do that means that debugging is a bit more difficult with all the extra messages (or more difficult since I need to fiddle with the settings). Imagine explaining to someone who looked why there's an error when it's expected. This is the ridiculousness that makes some build tools say "If you see an error, it's ok". — Eli Barzilay, Nov 14 '22 at 15:20
I stand 100% by my original post. I spend the first 3/4 of my response suggesting how the OP *CAN* catch (and, more importantly, *HANDLE*) exceptions. I also noted the importance of familiarizing himself with Chrome (or, for that matter, Edge or Mozilla) Developer Tools. Which can notify you of exceptions you didn't happen to anticipate/code for. I would argue that "First-Chance Exceptions" *ARE* a good thing. An important thing to be aware of, and utilize whenever appropriate during development. — paulsm4, Nov 14 '22 at 20:10
I think this answer/post needs to say clearly at the top that the __messages cannot be suppressed__ as misleads the reader to think it can be achieved with error handlers. Your reply with regards to error handling is good, but it seems like suppressing annoying websocket messages is impossible to do in the code at the moment. — ElDog, Feb 23 '23 at 09:55

A way to stop WebSocket errors to show up in browser's console

1 Answers1