API calls can fail. Network drop, bad argument, expired auth token. Without a try/except, a failed call crashes your script.
try:
result = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": -1})
print("ok")
except Exception as e:
print(type(e).__name__)Exception catches anything?
Pretty much. Exception is the parent of most error types you'll meet. as e binds the error to a name so you can inspect it. type(e).__name__ is the class name of the error — RuntimeError, TypeError, etc. Useful for logging without dumping a full traceback.
What kinds of errors does Composio throw?
Mostly RuntimeError for tool-level failures (with a message describing what went wrong), and the special string AUTH_REQUIRED:<app> when the OAuth token has expired. The platform catches AUTH_REQUIRED and pops a re-connect dialog before your script's except can see it — so in practice you write try/except for transient errors, not auth.
try/except for tool callsNetwork code is the natural home of try/except. Wrap every API call you can't guarantee will succeed:
try:
result = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": 5})
messages = result.get("messages", [])
except Exception as e:
print(f"Gmail fetch failed: {type(e).__name__}: {e}")
messages = [] # graceful fallbackexcept Exception catches almost anything. As you get more specific, you might write:
except RuntimeError as e:
# Composio's preferred error type
...
except ValueError as e:
# bad argument shape
...For a week-1 lesson, broad is fine. The platform's AUTH_REQUIRED flow is handled at a higher layer — your code won't see auth errors normally.
type(e).__name__ gives youtry:
int("not a number")
except Exception as e:
print(type(e).__name__) # ValueErrorClean, single-word identification of the error class. Better for logs and quick diagnostics than the full message, which might include long stack traces.
For today: catch broadly, print a class name, move on.
API calls can fail. Network drop, bad argument, expired auth token. Without a try/except, a failed call crashes your script.
try:
result = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": -1})
print("ok")
except Exception as e:
print(type(e).__name__)Exception catches anything?
Pretty much. Exception is the parent of most error types you'll meet. as e binds the error to a name so you can inspect it. type(e).__name__ is the class name of the error — RuntimeError, TypeError, etc. Useful for logging without dumping a full traceback.
What kinds of errors does Composio throw?
Mostly RuntimeError for tool-level failures (with a message describing what went wrong), and the special string AUTH_REQUIRED:<app> when the OAuth token has expired. The platform catches AUTH_REQUIRED and pops a re-connect dialog before your script's except can see it — so in practice you write try/except for transient errors, not auth.
try/except for tool callsNetwork code is the natural home of try/except. Wrap every API call you can't guarantee will succeed:
try:
result = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": 5})
messages = result.get("messages", [])
except Exception as e:
print(f"Gmail fetch failed: {type(e).__name__}: {e}")
messages = [] # graceful fallbackexcept Exception catches almost anything. As you get more specific, you might write:
except RuntimeError as e:
# Composio's preferred error type
...
except ValueError as e:
# bad argument shape
...For a week-1 lesson, broad is fine. The platform's AUTH_REQUIRED flow is handled at a higher layer — your code won't see auth errors normally.
type(e).__name__ gives youtry:
int("not a number")
except Exception as e:
print(type(e).__name__) # ValueErrorClean, single-word identification of the error class. Better for logs and quick diagnostics than the full message, which might include long stack traces.
For today: catch broadly, print a class name, move on.
Create a free account to get started. Paid plans unlock all tracks.