XLA 錯誤會依據不同的 XLA 錯誤來源分類。每個來源都會列出錯誤訊息以外的其他背景資訊，並附加至類別中的每個錯誤。
🚧 請注意，這項標準化作業仍在進行中，因此並非所有錯誤訊息都會附上錯誤代碼。
錯誤記錄範例如下：
XlaRuntimeError: RESOURCE_EXHAUSTED: XLA:TPU compile permanent error. Ran out of memory in memory space hbm. Used 49.34G of 32.00G hbm. Exceeded hbm capacity by 17.34G. Total hbm usage >= 49.34G: reserved 3.12M program unknown size arguments 49.34G
JaxRuntimeError: RESOURCE_EXHAUSTED: Ran out of memory in memory space vmem while allocating on stack for %ragged_latency_optimized_all_gather_lhs_contracting_gated_matmul_kernel.18 = bf16[2048,4096]{1,0:T(8,128)(2,1)} custom-call(%get-tuple-element.18273, %get-tuple-element.18274, %get-tuple-element.18275, %get-tuple-element.18276, %get-tuple-element.18277, /*index=5*/%bitcast.8695, %get-tuple-element.19201, %get-tuple-element.19202, %get-tuple-element.19203, %get-tuple-element.19204), custom_call_target=""
狀態和 CHECK 失敗
一般來說，在 XLA 中，我們可以透過兩種機制標記損毀的執行作業：狀態和 CHECK 巨集失敗。
狀態適用於可復原的非嚴重錯誤。假設函式會傳回，且執行作業會繼續沿著路徑進行，而呼叫端會明確檢查傳回的 Status 物件。這項功能有助於處理無效的使用者輸入內容或預期的資源限制。
另一方面，CHECK 失敗涵蓋程式設計師的錯誤或違反不變量的行為，如果程式碼正確，這類情況絕不應發生。如果啟用 CHECK 程式，系統會記錄錯誤訊息並立即終止。這可確保內部一致性，例如在取消參照指標前，檢查指標是否為非空值。
錯誤代碼
以下是所有錯誤代碼的索引清單。