[BUG] Bare Exception() raised with no message during response parsing, making debugging impossible #136

New issue

Open

opened 2026-02-13 17:27:55 -06:00 by mirrors · 2 comments

mirrors commented

2026-02-13 17:27:55 -06:00

Owner

Originally created by @ww2283 on GitHub (Jan 14, 2026).

Description:

When response parsing fails in generate_content(), the library raises bare Exception() with no message, making it impossible to diagnose what went wrong.

Observed Behavior:

When calling chat.send_message(), the request succeeds (chat session appears in Gemini WebUI), but the response parsing fails silently:

try:
response = await chat.send_message(prompt, ...)
except Exception as e:
print(f"Error: {e}") # Prints: "Error: " (empty!)
print(f"Type: {type(e)}") # Prints: <class 'Exception'>

The exception has no message, providing zero diagnostic information.

Root Cause:

In client.py, there are bare raise Exception statements with no message:

Line 375-376:
if not body:
raise Exception # No message!

Line 401-402:
case _:
raise Exception # No message!

Expected Behavior:

All exceptions should include diagnostic information:

if not body:
raise GeminiError("Response body is empty - parsing failed")

case _:
raise GeminiError(f"Unknown error code: {e_c}")

Impact:

Impossible to debug why requests fail
Callers cannot provide meaningful error messages to users
Request actually succeeds server-side but client reports failure with no explanation

Environment:

gemini_webapi version: (check with pip show gemini-webapi)
Python 3.10+

Trigger condition:
Sending a message with file attachments (2-3 files, ~10-20KB each) to gemini-3.0-pro.
The request succeeds server-side (visible in Gemini WebUI as a new chat session),
but the response parsing fails silently.

Debug output observed:
gemini_webapi.utils.parsing:get_nested_value - Safe navigation: path [4] ended at index 0 (key '4'), returning default.

Hypothesis:
When Gemini 3.0 Pro uses extended "thinking" time (especially with file analysis),
the response structure may differ from expected format - specifically, the output
may not be at index [4] where the parser expects it:

# client.py line 368-372
if get_nested_value(part_json, [4]):  # Output expected at [4]
    body_index, body = part_index, part_json

When this fails, body stays empty, triggering the bare raise Exception.

Suggested Fix:

Replace all bare raise Exception with descriptive raise GeminiError("...") including:

What operation failed
What was expected vs received
Any available context (error codes, response snippets)

Originally created by @ww2283 on GitHub (Jan 14, 2026). Description: When response parsing fails in generate_content(), the library raises bare Exception() with no message, making it impossible to diagnose what went wrong. Observed Behavior: When calling chat.send_message(), the request succeeds (chat session appears in Gemini WebUI), but the response parsing fails silently: try: response = await chat.send_message(prompt, ...) except Exception as e: print(f"Error: {e}") # Prints: "Error: " (empty!) print(f"Type: {type(e)}") # Prints: <class 'Exception'> The exception has no message, providing zero diagnostic information. Root Cause: In client.py, there are bare raise Exception statements with no message: Line 375-376: if not body: raise Exception # No message! Line 401-402: case _: raise Exception # No message! Expected Behavior: All exceptions should include diagnostic information: if not body: raise GeminiError("Response body is empty - parsing failed") case _: raise GeminiError(f"Unknown error code: {e_c}") Impact: - Impossible to debug why requests fail - Callers cannot provide meaningful error messages to users - Request actually succeeds server-side but client reports failure with no explanation Environment: - gemini_webapi version: (check with pip show gemini-webapi) - Python 3.10+ Trigger condition: Sending a message with file attachments (2-3 files, ~10-20KB each) to gemini-3.0-pro. The request succeeds server-side (visible in Gemini WebUI as a new chat session), but the response parsing fails silently. Debug output observed: gemini_webapi.utils.parsing:get_nested_value - Safe navigation: path [4] ended at index 0 (key '4'), returning default. Hypothesis: When Gemini 3.0 Pro uses extended "thinking" time (especially with file analysis), the response structure may differ from expected format - specifically, the output may not be at index `[4]` where the parser expects it: ```python # client.py line 368-372 if get_nested_value(part_json, [4]): # Output expected at [4] body_index, body = part_index, part_json ``` When this fails, body stays empty, triggering the bare raise Exception. Suggested Fix: Replace all bare raise Exception with descriptive raise GeminiError("...") including: 1. What operation failed 2. What was expected vs received 3. Any available context (error codes, response snippets)

mirrors commented

2026-02-13 17:27:55 -06:00

Author

Owner

@HanaokaYuzu commented on GitHub (Feb 4, 2026):

Hey, could you please help to check if this behavior persists in the latest version?

@HanaokaYuzu commented on GitHub (Feb 4, 2026): Hey, could you please help to check if this behavior persists in the latest version?

mirrors commented

2026-02-13 17:27:55 -06:00

Author

Owner

@ww2283 commented on GitHub (Feb 4, 2026):

Ok I will let you know in about 2 days; I might be slower in validating this on the newer code because my usage are pointing to my fork now. Once I switch and test I will let you know.

@ww2283 commented on GitHub (Feb 4, 2026): Ok I will let you know in about 2 days; I might be slower in validating this on the newer code because my usage are pointing to my fork now. Once I switch and test I will let you know.