docs: fix example in server.rst with more explicit exception handling

[voiduin]

@miguelgrinberg, thank you for this project - it's very useful!

I started using python-socketio in my project but encountered a bug that took me considerable time to debug.

My client wasn't receiving the connect_error event, and I tried changing server/client versions, reviewing my code multiple times, and other troubleshooting steps.

Thanks to this comment, I was able to identify the issue.

I noticed that even in your own test files, you don't use this shortened version anywhere:

            side_effect=exceptions.ConnectionRefusedError('fail_reason')

Reference: https://github.com/miguelgrinberg/python-socketio/blob/f8a1d435b23df74e720cb1c384955ff5dd1c442c/tests/async/test_server.py#L474C13-L474C73

Suggestion: Please update the documentation example to use the full exception name instead of the shortened version.

Using the full module path (e.g., socketio.exceptions.ConnectionRefusedError) would make the examples consistent with your own codebase and much clearer for newcomers to understand.Retry

[miguelgrinberg]

I'm sorry about this, I did not pick up the inconsistency between the two exception classes when it was mentioned before. I think instead of changing the example we can do better and handle both classes. Is this something you'd like to attempt yourself, or should I do it myself?

[voiduin]

I'm sorry about this, I did not pick up the inconsistency between the two exception classes when it was mentioned before. I think instead of changing the example we can do better and handle both classes. Is this something you'd like to attempt yourself, or should I do it myself?

@miguelgrinberg thank you so much for looking into this!

I’m not really familiar with the project’s internals, so unfortunately I wouldn’t be able to make the change myself. I’d really appreciate it if you could handle it.

---

PS: By the way, updating the documentation example might also be a good idea — many people (myself included) are using clients on older Debian systems, where version 5.0.3 (in my case) is still pinned.
https://packages.debian.org/search?keywords=python3-socketio

In such cases, we often refer to the latest online documentation, which can cause confusion.

It could also be useful to have online access to older documentation versions (at least for releases like 5.0.3 and other Debian-packaged ones), so users don’t have to build them locally — though that’s more of a nice-to-have than a real issue.