LangChain Mastery

Course Content

LangChain Mastery

7 sections · 109 lessons

What is a try-except block in LangChain applications?

What you need to know

Where exceptions come from

ExceptionRaised byMeaningUsual response
openai.RateLimitError (429)Provider SDKToo many requestsRetry with backoff
openai.APITimeoutError, APIConnectionErrorProvider SDKNetwork or slow responseRetry, then fall back
openai.InternalServerError (5xx)Provider SDKProvider outageRetry, then fall back to another provider
openai.BadRequestError (400)Provider SDKBad request, context too longFix the input; don't retry
OutputParserExceptionlangchain_core.exceptionsModel reply didn't match the formatRe-ask or repair once
pydantic.ValidationErrorYour schemasInput or output failed validationReject or repair

LangChain's provider packages (langchain-openai, langchain-anthropic) let the SDK's exceptions pass through, so you catch the provider's classes.

A targeted handler

Python
import loggingimport openaifrom langchain_core.exceptions import OutputParserExceptionlog = logging.getLogger(__name__)def answer(question: str) -> str:    try:        return chain.invoke({"question": question})    except OutputParserException:        log.warning("parse_failure")        return repair_chain.invoke({"question": question})   # one repair attempt    except openai.BadRequestError as e:        log.error("bad_request", extra={"status": e.status_code})        return "Your question is too long. Please shorten it."    except openai.APIError:        log.exception("provider_error")        return "The assistant is busy. Please try again in a minute."

Order matters: specific classes before general ones. openai.APIError is the parent of the rate-limit, timeout and status errors.

Declarative handling on runnables

Python
robust = chain.with_retry(    retry_if_exception_type=(openai.RateLimitError, openai.APITimeoutError),    stop_after_attempt=3,).with_fallbacks([backup_chain])

This keeps retry and fallback logic next to the chain, and each attempt shows up in traces. In agents built with create_agent, the same ideas come as middleware: ModelRetryMiddleware, ModelFallbackMiddleware, ToolRetryMiddleware.

A real-life example

A finance assistant calls a stock-price API tool and a model. Early code wrapped everything in except Exception: return "Something went wrong". During a market-open spike, the model provider returned 429s for 3 minutes; users saw "Something went wrong" and support tickets tripled. Logs had no detail, so nobody knew it was rate limiting.

The fix: with_retry on the model for 429s and timeouts (3 attempts, exponential backoff with jitter), a fallback to a second provider, and a narrow try/except at the API edge that logs the exception class and returns a specific message. The next spike caused a 1.5-second slowdown for some users instead of failures.

Follow-up questions to expect

  • "Why not catch Exception?" — It hides bugs (like a KeyError in your own code) behind a generic message and makes you retry things that will never succeed.
  • "Where do you put the try?" — At the boundary where you can do something useful: the API handler or a tool wrapper — not around every line.
  • "What about async?" — The same exceptions are raised from ainvoke; handle them the same way.