Fix #3464: Correct misleading exception_handler example in docs

[byeongjulee222]

Pull Request check-list

Please make sure to review and check all of these items:

• Do tests and lints pass with this change?
• Do the CI tests pass with this change (enable it first in your forked repo and wait for the github action build to finish)?
• Is the new or changed code fully tested?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?
• Is there an example added to the examples folder (if applicable)?
• Was the change added to CHANGES file?

NOTE: these things are not required to open a PR and can be done
afterwards / while the PR is open.

Description of change

This Pull Request addresses issue #3464 by correcting the misleading example in the docs/advanced_features.rst file regarding the exception_handler for run_in_thread.

• The updated documentation ensures the example does not cause a RuntimeError when thread.join() is called from the same thread.
• The corrected example demonstrates best practices for handling exceptions, cleaning up PubSub connections, and stopping threads safely.
• The documentation update includes improvements to clarify the usage of exception_handler to avoid common pitfalls.

This change affects only the documentation and does not alter the library’s functionality or API.

[byeongjulee222]

@vladvildanov
Hello team,

I submitted this PR (#3474) to address issue #3464 by correcting the misleading exception_handler example in the documentation. I haven’t seen any feedback yet and would appreciate your input on whether there are any issues with the changes.

Specifically, I’d like to know:
• If the updated example accurately demonstrates best practices for handling exceptions and cleaning up PubSub connections.
• Whether the ordering of the exception handling and cleanup logic might lead to any unforeseen runtime issues.
• Any other improvements or modifications you’d suggest to ensure the documentation is clear and aligns with our coding standards.

Thank you for taking the time to review my changes. I look forward to your feedback!

[petyaslavova]

Hi @byeongjulee222, your change looks good! I was just wondering whether it might be a good idea to keep the Pub/Sub closing statement in the handler—not as a strict requirement, but as a reminder that the channel should be closed...
But since closing Pub/Sub is not the main focus of this example and the next section specifically covers that topic, it should be fine to leave it as is.

[byeongjulee222]

Hi @petyaslavova, thanks for the thoughtful suggestion!
Since the next section explicitly covers closing Pub/Sub, I’d prefer to keep it as is for clarity. Appreciate your review!