Docs can go missing — the id might be wrong, the doc might be deleted, the caller might typo. How should your function react when the API itself raises?
Wrap the call in try/except and return an empty string if anything fails?
Exactly. GOOGLEDOCS_GET_DOCUMENT_BY_ID raises an exception when an id doesn't exist. Catch it, log nothing to the caller, return "":
try:
result = toolset.execute_action(Action.GOOGLEDOCS_GET_DOCUMENT_BY_ID, {"id": doc_id})
return result.get("title", "")
except Exception:
return ""
Catching Exception feels broad. Shouldn't I catch the specific error the API raises?
In production, yes — a specific exception class is better. For a defensive read that only returns a string, catching broadly is acceptable: the caller cares whether a title came back, not why it did not. Same pattern wraps any risky API call:
def get_doc_title(doc_id: str) -> str:
try:
result = toolset.execute_action(Action.GOOGLEDOCS_GET_DOCUMENT_BY_ID, {"id": doc_id})
return result.get("title", "")
except Exception:
return ""
What about when the call succeeds but the response has no title key at all?
That is exactly why .get("title", "") sits on the success path. Two layers of safety: except catches raised errors, .get with a default catches missing keys. Together your function returns "" for every bad case and the real title for every good one.
So any caller of get_doc_title gets a string back no matter what? They never have to handle an exception themselves?
Defensive reads are gifts to the caller — one return type, no surprises. That discipline is exactly what Week 4 needs when you start chaining APIs together.
TL;DR: Wrap the API call in try/except so missing ids return "" instead of crashing the caller.
Action.GOOGLEDOCS_GET_DOCUMENT_BY_IDid (the document id).get("title", "") guards a missing keyexcept Exception: return "" guards a raise| Layer | Handles |
|---|---|
try/except | network error, deleted doc, bad id |
.get(key, default) | missing key in a 200 response |
Docs can go missing — the id might be wrong, the doc might be deleted, the caller might typo. How should your function react when the API itself raises?
Wrap the call in try/except and return an empty string if anything fails?
Exactly. GOOGLEDOCS_GET_DOCUMENT_BY_ID raises an exception when an id doesn't exist. Catch it, log nothing to the caller, return "":
try:
result = toolset.execute_action(Action.GOOGLEDOCS_GET_DOCUMENT_BY_ID, {"id": doc_id})
return result.get("title", "")
except Exception:
return ""Catching Exception feels broad. Shouldn't I catch the specific error the API raises?
In production, yes — a specific exception class is better. For a defensive read that only returns a string, catching broadly is acceptable: the caller cares whether a title came back, not why it did not. Same pattern wraps any risky API call:
def get_doc_title(doc_id: str) -> str:
try:
result = toolset.execute_action(Action.GOOGLEDOCS_GET_DOCUMENT_BY_ID, {"id": doc_id})
return result.get("title", "")
except Exception:
return ""What about when the call succeeds but the response has no title key at all?
That is exactly why .get("title", "") sits on the success path. Two layers of safety: except catches raised errors, .get with a default catches missing keys. Together your function returns "" for every bad case and the real title for every good one.
So any caller of get_doc_title gets a string back no matter what? They never have to handle an exception themselves?
Defensive reads are gifts to the caller — one return type, no surprises. That discipline is exactly what Week 4 needs when you start chaining APIs together.
TL;DR: Wrap the API call in try/except so missing ids return "" instead of crashing the caller.
Action.GOOGLEDOCS_GET_DOCUMENT_BY_IDid (the document id).get("title", "") guards a missing keyexcept Exception: return "" guards a raise| Layer | Handles |
|---|---|
try/except | network error, deleted doc, bad id |
.get(key, default) | missing key in a 200 response |
Create a free account to get started. Paid plans unlock all tracks.