Skip to main content
Structured exceptions tell you what failed, whether to retry, and which agent or run was involved — without parsing raw tracebacks.
The user runs the agent; failures raise typed PraisonAIError with category, message, and run context for recovery.

Quick Start

1

Catch any agent error

2

Handle tool errors specifically


How It Works

Every structured error carries message, agent_id, run_id, error_category, and is_retryable. Subclasses add domain fields such as tool_name or model_name. error_category uses typed kinds such as rate_limit, auth, context_overflow, and billing.

Common Patterns

Retry on transient network failures, fail on config bugs:
Raised errors stop the run; some callbacks record failures on the output instead. See Non-Fatal Errors.

Reaching the Step Limit

When the tool-calling loop reaches ExecutionConfig.max_steps (or max_iter when max_steps is unset), the agent does not hard-cut. On the final permitted step it injects a graceful wrap-up instruction, so the model returns a real summary of what it accomplished and what remains — not a placeholder. Detect truncation with agent.last_stop_reason instead of string-matching:

Step Budget

Cap tool-use steps and detect graceful truncation with last_stop_reason

Best Practices

Use ToolExecutionError when you only care about tool failures; reserve PraisonAIError for top-level logging.
Include e.error_category, e.agent_id, and e.run_id in observability hooks — they correlate across multi-agent runs.
Validation failures usually mean a programming or config bug. Fix the root cause instead of retrying blindly.
Loop-guard HALT raises ToolExecutionError. Combine with Loop Guard when tools may repeat indefinitely.

Loop Guard

Stop runaway tool loops with HALT/WARN/BLOCK

Non-Fatal Errors

Callback failures captured without crashing