Skip to main content

Overview

core-ai provides a hierarchy of error classes for handling different types of failures when working with language models. All errors extend from CoreAIError and provide structured error information.

Error Hierarchy

CoreAIError

Base error class for all core-ai errors.

ValidationError

Thrown when core-ai rejects invalid caller input or local request configuration before calling a provider.

Properties

string
Error message describing what went wrong.
unknown
Optional underlying cause of the error (e.g., network error, API error).
string | undefined
Optional provider context when the error can be attributed to a provider.
string
Error name, always 'ValidationError'.

Example

UnsupportedInputModalityError

Thrown when user messages include content parts the model does not accept, before the provider call. Extends ValidationError.

Properties

readonly string[]
Modalities present in the user messages.
readonly string[]
Modalities from model.capabilities.modalities.input.
readonly string[]
Requested modalities missing from the model capabilities.

Example

AbortedError

Thrown when an operation is cancelled via an AbortSignal.

StreamAbortedError

Thrown when a streaming operation is aborted via an AbortSignal.

Example

ProviderError

Error for provider/API failures. Discriminate with subclasses and instanceof. Transient failures extend RetryableProviderError.

Properties

string
The provider that threw the error (e.g., 'openai', 'anthropic').
number | undefined
HTTP status code if available (e.g., 404, 500, 429).

Classified subclasses

Each provider wrap*Error helper decides which subclass to throw from SDK-specific fields (error types, status codes, message shapes). Use instanceof to branch in application code — statusCode is for logging and debugging, not for retry decisions. HTTP 429 is not always RateLimitError: billing quota (for example OpenAI insufficient_quota) remains a non-retryable ProviderError, while some capacity signals (for example Azure NoCapacity) map to ModelOverloadedError. RateLimitError.retryAfterSeconds may come from Retry-After, Azure retry-after-ms, or an HTTP-date Retry-After header.

Example

StructuredOutputError

Base class for errors related to structured output generation (objects).

Properties

string | undefined
The raw output from the model that failed to parse/validate.

Example

StructuredOutputNoObjectGeneratedError

Thrown when the model doesn’t generate an object at all.

Example

StructuredOutputParseError

Thrown when the model’s output cannot be parsed as JSON.

Example

StructuredOutputValidationError

Thrown when the model’s output doesn’t match the Zod schema.

Properties

string[]
Array of validation error messages from Zod.

Example

Error Handling Patterns

Comprehensive Error Handling

Retry Logic with Error Handling

Logging and Monitoring

Graceful Degradation

Best Practices

Always check for specific error types before general ones. Use instanceof checks in order from most specific to least specific.
Don’t retry validation errors (StructuredOutputValidationError) - they indicate a schema mismatch that won’t be fixed by retrying.
Gate retries on RetryableProviderError — the umbrella for transient failures (rate limits, overload, and transient 5xx) — with exponential backoff. Don’t treat every HTTP 429 as retryable: billing quota errors surface as a non-retryable ProviderError.
The rawOutput property in structured output errors is useful for debugging what the model actually generated.
Log error details including provider, status codes, and causes for debugging and monitoring.