Support for emitting warnings on socket use instead of failing?

[msabramo]

Is it possible to do a softer approach where a warning is logged instead of failing?

[miketheman]

I guess that could technically be added, but I'd prefer to keep the library targeted towards raising failure, since warnings often get ignored.

Can you elaborate on why warnings would be preferable to raising exceptions?

[khakulov]

@miketheman

The specific reason I need a warning/logging mode is that I am dealing with a legacy codebase where broad

try:
    ...
except Exception:
    ...

blocks exist.

In these blocks, errors are caught and handled silently (swallowed) without logging. If the library simply raises a SocketBlockedError, my application code catches that exception and ignores it. As a result, the test passes, and I have absolutely no visibility that an external API call was attempted and blocked.

A warning (or a logging side-effect) would allow the information to bubble up to the test console/logs independent of the application's flow control, alerting me to the external dependency even if the application suppresses the error."

One of the examples for such a code:

def get_address(lat, lon):
    try:
        nominatim = Nominatim(user_agent=USER_AGENT)
        location = geo.reverse((lat, lon), timeout=10)
        return location.address
    except Exception:
        pass
    
    try:
        response = requests.get(
            url='https://maps.googleapis.com/maps/api/geocode/json',
            json={"latlng": f"{lat},{lon}", "key": API_KEY}
        )
        response.raise_for_status()
        response_json = response.json()
        response_json["results"][0]["formatted_address"]
    except Exception:
        pass

    return ""

[khakulov]

I'd like to propose that logging/warnings serve two distinct, valuable use cases that a simple SocketBlockedError cannot cover:

1. Visibility (Log + Raise) As mentioned regarding the catch-all exception blocks: If the library only raises an exception, and my application code swallows it, the test passes with a false positive. I believe the request was blocked, but it wasn't reported. Requirement: I need a log entry printed to stderr/warnings before the exception is raised. This ensures that even if the exception disappears into a try/except block, the test output still clearly indicates that a blockage occurred.

2. Migration / Audit Mode (Log Only) I am introducing this tool into a large, existing legacy codebase. Enabling disable_socket immediately causes hundreds of tests to fail, which halts our development pipeline. I cannot fix them all at once. Requirement: I need a "soft mode" (or "audit mode") that allows the connection but logs a warning. This allows me to enable the plugin globally, collect a list of all offending tests, and fix them incrementally (step-by-step) without breaking the build. Once the logs are clean, I can switch to the strict "Raise Exception" mode.