Fix access to cleared exception variable in openrouter_client.py

[Fallen-Breath]

Problem

deepwiki-open/api/openrouter_client.py

Lines 339 to 345 in 3444d0b

	except Exception as e_unexp:
	log.error(f"Unexpected error calling OpenRouter API asynchronously: {str(e_unexp)}")
	# Return a generator that yields the error message
	async def unexpected_error_generator():
	yield f"Unexpected error calling OpenRouter API: {str(e_unexp)}"
	return unexpected_error_generator()

The exception variable e_unexp is referenced after the except block ends, causing NameError being raised inside the unexpected_error_generator function

There are also some other except statements in the openrouter_client.py that have the same issue

deepwiki-open/api/openrouter_client.py

Lines 323 to 337 in 3444d0b

	except aiohttp.ClientError as e_client:
	log.error(f"Connection error with OpenRouter API: {str(e_client)}")
	# Return a generator that yields the error message
	async def connection_error_generator():
	yield f"Connection error with OpenRouter API: {str(e_client)}. Please check your internet connection and that the OpenRouter API is accessible."
	return connection_error_generator()
	except RequestException as e_req:
	log.error(f"Error calling OpenRouter API asynchronously: {str(e_req)}")
	# Return a generator that yields the error message
	async def request_error_generator():
	yield f"Error calling OpenRouter API: {str(e_req)}"
	return request_error_generator()

Impact

It's the cause of error logs like this

Error with OpenRouter API: cannot access free variable 'e_unexp' where it is not associated with a value in enclosing scope

It also hide the real exception message from the e_unexp (and also e_req and e_client)

References

FYI: https://docs.python.org/3.13/reference/compound_stmts.html#except-clause

When an exception has been assigned using as target, it is cleared at the end of the except clause. This is as if

except E as N:
    foo

was translated to

except E as N:
    try:
        foo
    finally:
        del N

This means the exception must be assigned to a different name to be able to refer to it after the except clause. Exceptions are cleared because with the traceback attached to them, they form a reference cycle with the stack frame, keeping all locals in that frame alive until the next garbage collection occurs.

[gemini-code-assist]

Summary of Changes

Hello @Fallen-Breath, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request fixes a subtle but critical bug in Python exception handling within openrouter_client.py. It addresses the issue where exception variables, when caught using except E as N, are cleared at the end of the except block, a behavior that can lead to NameError when attempting to access these variables later. The changes ensure that caught exceptions are properly preserved and accessible for logging and generating informative error messages, thereby enhancing the reliability of error reporting for OpenRouter API interactions.

Highlights

• Python Exception Handling: Addressed a NameError issue where exception variables were being referenced after being cleared at the end of except blocks, a behavior introduced in Python 3.13.
• Error Logging and Reporting: Ensured that actual exception messages are correctly captured and logged, preventing them from being hidden due to the cleared exception variable.
• Code Robustness: Improved the robustness of error handling within the openrouter_client.py by correctly preserving exception details for logging and error message generation.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly fixes a NameError caused by accessing an exception variable after its scope has ended. The fix works by re-assigning the exception to a new variable. I've suggested a further refinement to this approach: instead of preserving the entire exception object, it's better to capture only the error message as a string. This is more memory-efficient and is a cleaner way to handle this pattern.