Skip to main content

TheoApiError

所有 REST API 錯誤都會以帶有結構化詳情的 TheoApiError 實例拋出。

錯誤屬性

錯誤類型

TheoApiError 是基類 —— 下面每種錯誤都是 TheoApiError 的實例,因此現有的 catch 代碼塊仍然可以正常工作。若需要精確處理,請基於子類(或 err.kind)分支:
  • TheoTimeoutError(kind: "timeout")—— SDK 在 timeoutMs(單次請求 / 流連接)或 streamIdleTimeoutMs(流空閒)超時後主動中止。相關超時預算保存在 .timeoutMs 中。不會在 POST 請求上自動重試。
  • TheoCancelledError(kind: "cancelled")—— 你通過 TheoStream.cancel() 或傳給 waitForJob() 的 AbortSignal 主動中止了請求。
  • TheoUsageError(繼承自 Error,而非 TheoApiError)—— 在發起任何網絡調用之前,因誤用而同步拋出,例如向 complete() / stream() 傳入 mode: "research" | "video"(應改用異步任務方法)。

流式錯誤

SSE 的 error 事件攜帶的信封結構與 REST 錯誤響應體相同——兩者可以複用同一套處理邏輯。
這一點與 0.1.x 版本不同,當時流式錯誤只有 { message }。完整的信封結構請參見流式補全參考文檔。

首次運行診斷

theo.verify() 不會直接拋出原始錯誤,而是返回帶有修復建議的結構化診斷結果:
遇到 401 錯誤時,應將此調用作為排查的第一步。常見故障場景請參見401 故障排查。

自動重試

SDK 會在以下情況下自動重試:
  • 429 —— 觸發限流(遵循 Retry-After 響應頭,最多等待 60 秒)
  • 5xx —— 服務器錯誤(指數退避:1 秒、2 秒、4 秒,最長 8 秒) 客戶端錯誤(400、401、403、404)不會被重試。非冪等的 POST 請求(complete、research、video)的超時不會被重試——重新發起請求可能導致請求被重複執行並重復計費;如果確實需要重試,請自行實現重試邏輯並配合 Idempotency-Key 使用。完整的重試模型(包括流式空閒超時)請參見超時與重試。 配置方式:

取消請求

TheoStream.cancel() 會中止正在進行的流式請求,且不會拋出異常。底層的 fetch 會通過 AbortController 被中止;後續事件將不再到達,迭代器會正常結束。