Client socket nonsense

Processing version: 3.5.4

Client got end-of-stream.
Client SocketException: Socket closed

Socket exception handling in Processing has proven to be nothing less than frustrating and an annoyance. An electronic chase around the Internet has only netted dead-ends, tons of misinformation by well-meaning but ill-informed contributors, and developers who have simply given up on catching socket exceptions. Looking for someone with socket expertise to address this issue and hoping that this topic will result in being an anchor on the Internet for a definitive solution that others can reference in the future.

ISSUE:
How to “catch” socket exceptions/errors/messages et al using try/catch.

import processing.io.*;
import processing.net.*;
import processing.serial.*;
import java.io.*;
import java.net.*;

Client xyz;

void setup()
{
    xyz = new Client(this, "www.google.com", 80);
    xyz.stop();
}

void draw()
{
}

RESULT:
“Client SocketException: Socket closed” is written to console. Well, yeah, I closed the socket intentionally.

Note that, if you connect to a server, write to it, read from it, and then issue {Client}.stop() when finished, you get “Client got end-of-stream.” message written to console. I don’t want either of these messages written to console.

I have tried the following:

import processing.io.*;
import processing.net.*;
import processing.serial.*;
import java.io.*;
import java.net.*;

Client xyz;

void setup()
{
    try {
        xyz = new Client(this, "www.google.com", 80);
        xyz.stop();
    } catch ( SocketException e ) {
        println ("DON'T CARE, DON'T TELL ME");
    }
}

void draw()
{
}

However the Processing IDE tells me, “Unreachable catch block for SocketException. This exception is never thrown from the try statement body”. Well, could have fooled me…and did…given that the program spits out a “Client SocketException” message to the console when it is run.

The question remains, how to use try/catch to handle these messages.

FYI, I know about {client}.active() as a workaround for functional purposes based upon success/failure of the connection. But that doesn’t stop the messages from going to console.