Troubleshooting with ErrLookup
Start from the failure class, watch the MCP server resolve a real error, or wire it into your own agent.
Failure class guides
Most production errors belong to a recognizable failure class. Each guide explains one class from the mechanism up and links every documented occurrence:
- Parsing and encoding errors: unexpected token, malformed input
Unexpected token, unexpected end of input, invalid UTF-8, malformed JSON: what parsers are really complaining about and how to locate the bad byte. (6,848 documented occurrences) - Authentication and authorization failures
401 vs 403, expired and malformed tokens, clock skew, and missing scopes: how auth failures surface as errors and how to debug them. (3,901 documented occurrences) - Error: deliberate library guards and refused operations
This family is the generic Error that a library throws on purpose, from its own code, when a caller violates a precondition it is not willing to paper over. A developer meets it not because of a type slip or a runtime engine fault, but because the library has decided that a configuration value, a payload shape, an environment, or a security posture is wrong enough that guessing would be worse than stopping. Across 54 repositories these throws share one shape — a synchronous, hand-worded message at a trust boundary — while differing widely in what triggered them. (3,783 documented occurrences) - Timeouts: ETIMEDOUT, deadlines, and hung requests
Connect timeouts vs read timeouts vs deadlines, why each one fires, and how to pick budgets that fail fast without flaking. (3,285 documented occurrences) - SSL/TLS and certificate errors
Expired certificates, self-signed chains, hostname mismatches, and handshake failures: what each TLS error means and the safe way to fix it. (2,702 documented occurrences) - Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries
"Type mismatch" errors fire when a value's runtime type doesn't fit what an API, converter or codec declared: from IllegalArgumentException and TypeError to custom guards like FlowableIllegalArgumentException. This article explains where the check lives, why it fires, and how 2,292 records across 150 libraries handle it. (2,292 documented occurrences) - CommandExecutionError: Command Ran, But the Result Was Wrong — Common Causes and Fixes
CommandExecutionError is a wrapper error thrown when a CLI command executed but something went wrong during that execution — a failed browser-automation step, an unexpected HTTP status, a malformed API payload, or a scrape that returned nothing the parser recognizes. Developers usually meet it in the jackwener/OpenCLI tooling (codex, reddit, bilibili, twitter, trip/ctrip, archive.org and other site adapters), where the message text after the prefix points at the real failure underneath. (2,073 documented occurrences) - ArgumentException — when a .NET method rejects an argument that breaks its contract
ArgumentException is the .NET exception thrown when a method receives an argument that is the right type but semantically invalid: an unrecognized enum token, a null where a value is required, an index past the valid range, or a name that collides with an existing one. Developers meet it at the call site, before any work begins, with a message that usually names the offending parameter and lists the valid values. Across the 2040 documented records spanning 75 repositories, it is the most common shape of fail-fast guard in the .NET ecosystem. (2,040 documented occurrences) - Conflicting config options: "cannot be used together" — configuration validation errors across open-source libraries
"Conflicting config options" errors — messages like "env and jsc.target cannot be used together", "must be provided together", or "only supported for" — appear when a library's config validation rejects mutually contradictory or ambiguous option combinations. Developers hit them at startup, build, or DDL time when one setting disables or contradicts another. (1,160 documented occurrences) - ExtractorError in yt-dlp and youtube-dl: what 'said:' messages, login-required errors, and 'Cannot parse data' mean
ExtractorError is what yt-dlp and youtube-dl raise when a per-site extractor cannot turn a page or API response into downloadable media: the content needs login, is geo-blocked or removed, the site changed its markup or API since your build was released, or your requests tripped rate limiting. The message often quotes the provider's own text ('YouTube said:', 'Tencent said:', 'This video is only available for registered users', 'Cannot parse data'), which names the real cause. This article covers the mechanisms behind the family's 1137 documented records and the fixes that hold across all of them. (1,137 documented occurrences) - ValueError: the wrong-value guard at the library boundary
ValueError is Python's built-in signal that an argument had the right type but an unacceptable value, and across the 31 repositories in this family it shows up most often as an eager check at a library's input boundary. A negative precision, a geodetic geometry paired with a linear Distance, an unknown function name inside a query string, or a path that escapes its directory are all refused before any real work begins. Developers meet it the instant a call crosses into library code with a value the library's own contract forbids, and the message almost always names the offending argument. (1,102 documented occurrences) - TypeError: Wrong Value Type at the API Boundary
TypeError is the built-in exception both Python and JavaScript use when a value is not the type an operation expects, and in these libraries it surfaces less as a language quirk than as a deliberate fail-fast guard. A factory refuses a non-object config, a hook loop rejects a bad return value, a validator catches a constraint placed on the wrong field type. Developers meet it the moment they hand an API a value that breaks its documented shape: at construction, during request handling, or while a schema is being built. (1,068 documented occurrences) - IOException in Java and C#: why libraries throw the generic I/O exception for everything from missing HID devices to "Unexpected code" HTTP responses
IOException is the checked-exception class Java (and the equivalent System.IO exception in C#) defines for failed or interrupted I/O, but in practice open-source libraries throw it for almost anything: a device that is not connected, a non-2xx HTTP status, a truncated binary file, an idle replication socket, a missing config key, even a dead child process. If you landed on this error, the message text and the wrapped cause matter far more than the class name, because the same IOException surfaces from hardware, network, filesystem, parser, and configuration layers depending on the library. (754 documented occurrences) - ArgumentNullException ("Value cannot be null"): when a .NET method rejects a null argument
ArgumentNullException with the message "Value cannot be null" is thrown when .NET code passes a null reference for an argument a method requires to be non-null. It is raised by explicit fail-fast guards in libraries such as Newtonsoft.Json, Hangfire, Orleans, MAUI, LiteDB, Unity, and Polly, and its ParamName names the offending argument. This page covers the mechanism behind the whole family, how the message varies across libraries, and the causes and fixes that hold no matter which library threw it. (701 documented occurrences) - ArgumentOutOfRangeException: .NET throws it when an argument value is out of range, empty, or hits an unmapped switch case
ArgumentOutOfRangeException is the .NET base-class-library exception a method throws when an argument's value falls outside its allowed range. Developers meet it most often as a synchronous throw at method entry naming the offending parameter via ParamName. Across the documented libraries it fires in three situations: a numeric value that went negative or oversized, a collection sized to zero where work was expected, or an enum/type value that fell through to a switch statement's default branch. The largest documented cluster is the zero-length case, where the type is sometimes used in place of the more idiomatic ArgumentException. (695 documented occurrences) - InvalidRequestException: invalid request rejected before execution in Cassandra, Hadoop and JuiceFS
InvalidRequestException means a library rejected an operation as invalid before or during execution — a malformed CQL tuple literal or mixed LWT condition in Apache Cassandra, a bad short-circuit slot request or bucket-root delete in Apache Hadoop, or an invalid native parameter in JuiceFS. This guide explains the mechanisms behind the family and how to fix each shape of it. (669 documented occurrences) - IllegalArgumentException: When a Java Library Rejects the Argument You Handed It
IllegalArgumentException is the unchecked RuntimeException Java libraries throw when a method receives an argument that is the wrong value, wrong type, wrong shape, or wrong count. Developers meet it at trust boundaries — configuration parsing, script compilation, generic-type construction, reflection-backed bean wiring — wherever a library chooses to fail fast on bad input instead of carrying it forward into a confusing later failure. Across the 658 records in this family it is rarely a bug in the library; it is almost always the caller handing it something its contract never agreed to accept. (658 documented occurrences) - OperationError in CyberChef — "Unknown algorithm version", "Invalid encoding", "Error loading image": one error class behind every operation failure
OperationError is the single error class CyberChef throws for every operation failure — "Unknown algorithm version", "Invalid encoding", "Error loading image. (${err})", "Invalid key length", and hundreds more. A developer meets it when a recipe or chef.bake / Recipe.run call passes an argument that misses a constrained option list, supplies malformed or truncated input, or triggers an underlying decoder or cipher that rejects the data. This article explains the shared mechanism behind the messages and the fixes that hold across the whole family. (585 documented occurrences) - NotSupportedException from Unity PlayerSettings.WSA: deprecated phone/store tile members that throw unconditionally
`NotSupportedException` is thrown by accessors of removed Windows Phone 8.1 and deprecated store visual-asset properties on `PlayerSettings.WSA` (for example `phoneSplashScreenImage`, `phoneMediumTile140`, `storeTileWideLogo140`). A developer meets it after touching a member that Unity gutted during its Windows Phone 8.1 to Universal Windows Platform migration: the member still exists, but its get and set bodies only `throw new NotSupportedException(...)`, while the message points at the replacement API. Direct compiled access is normally blocked first by `[Obsolete(..., true)]` (compile-time error CS0619), so the runtime throw surfaces mainly through reflection, dynamic dispatch, or stale assemblies that bypass the compiler check. (577 documented occurrences) - "is not a compatible type" / "cannot merge" errors: when a value's type doesn't match what the library requires
Errors like "source is not a compatible type", "failed to merge statements", and "instance is not a RGB image" all fire when a library checks a value's concrete type up front and refuses to proceed. These incompatible-source-type errors surface at config load, evaluation, scan, or deserialization time. Here is why they exist and how to fix them. (526 documented occurrences) - InvalidOperationException: Invalid State and Configuration Violations Across .NET Libraries
InvalidOperationException is the .NET exception a library throws when a call is legal in principle but wrong for the object's current state, or when an invariant the library guarantees would be violated by proceeding. Across the 485 documented records in this family, developers meet it most often inside EF Core (at model finalization and at LINQ-to-SQL translation time), inside ASP.NET Core's Blazor render pipeline, and occasionally inside Newtonsoft.Json's serialization adapters. It is almost always a deliberate, fail-loud guard: the library could silently return wrong data or corrupt internal structures, and chooses to throw instead. (485 documented occurrences) - RuntimeException: the generic unchecked failure libraries throw when the runtime breaks down
RuntimeException is the unchecked exception that PHP and Java libraries reach for when an error surfaces during execution that is neither a programming bug nor a condition the caller signed up to handle. In the ErrLookup corpus it spans Symfony, Composer, Elasticsearch, Gson, and the ASP.NET Core SignalR Java client, and it appears in three roles: a fail-fast guard against an incompatible environment, a wrapper that adds context to a lower-level failure, and a hard stop when a resource or external dependency is unavailable. Developers meet it at autoload time, during console commands, inside build plugins, and while deserializing objects. (466 documented occurrences) - EmptyResultError: What the EMPTY_RESULT Error Code Means and How to Fix It
EmptyResultError (error code EMPTY_RESULT) is a typed error thrown when a command or API call succeeded but returned no usable data — an empty array, a blank payload, a page that rendered nothing, or a 404 on a lookup. Developers usually meet it when scripting CLI commands or automation wrappers around web pages and APIs: the run did not crash and was not blocked, but there was genuinely nothing to return, and the library refuses to hand back an empty result that could be mistaken for success. (434 documented occurrences) - ToolError: Tool Execution Failed — What This Error Class Means and How to Fix It
ToolError is an error class raised by agent frameworks and tool runtimes (such as oh-my-pi and OpenManus) when a tool call — a browser action, file read/write, session operation, or model-backed helper — cannot complete. This page explains the common mechanisms behind ToolError, the typical triggers (missing parameters, unsupported capabilities, changed or invalid session state, unreachable infrastructure), and the fixes and prevention habits that hold across the family. (422 documented occurrences) - eyre::Report: Rust bail!/ensure! errors like 'invalid tool path' and 'git failed with status' explained (mise)
eyre::Report is the error type Rust programs built on the eyre crate throw with bail! and ensure!, so you meet it as a one-line, self-describing message such as 'invalid tool path ... contains forbidden character' or 'archive does not contain registry entries' whenever an internal guard rejects a value, a download, or an environment before work continues. In mise, the best-documented source of this family, these errors mark shell-safety and path-traversal boundaries, corrupt caches and truncated downloads, stale lockfiles and plans, and platform limits like glibc-only Homebrew bottles. Because every message is written by hand at each call site, the message text itself is the diagnosis: it names the offending value and the expectation it failed. (408 documented occurrences) - UnsupportedOperationException in Java libraries: what this error means, why libraries throw it on purpose, and how to fix it
UnsupportedOperationException is Java's standard signal that a method exists on a type but the concrete implementation refuses to perform it. This article covers the whole error family across 31 repositories — Flink, Elasticsearch, Ghidra, Dubbo, Spring, RxJava, Gson, Jackson, Keycloak and others — and shows when developers meet it: calling interface methods generically on special implementations, using features a subtype cannot support by design, violating runtime invariants like expired session-window merges, running components in the wrong execution mode, or hitting OS-level sandbox limits. Most instances are deterministic contract statements, not transient failures, so the fix is to change the call path rather than retry. (397 documented occurrences) - InvalidArgumentException in PHP: contract violations, bad config, and malformed input across Symfony, Guzzle, Laravel, and Composer
InvalidArgumentException (\InvalidArgumentException) is the error major PHP libraries throw when a caller breaks a contract — passing a value of the wrong type, a malformed DSN or URL, a misconfigured service tag, an unsupported cURL option, or a missing interface method. You meet it the moment your code hands the library something it cannot use, before any real work begins. This article explains the mechanism behind the family across Symfony, Guzzle, Laravel, and Composer, the recurring shapes it takes, and the cross-library fixes that resolve the bulk of cases. (367 documented occurrences) - HTTP status errors: handling 4xx and 5xx responses
Which HTTP status codes are your bug, which are the server's, which are retryable, and how libraries surface them as errors. (362 documented occurrences) - TypeORMError explained: why TypeORM throws its base error class for bad decorators, where filters, and schema mismatches
TypeORMError is the base error class TypeORM throws for configuration defects, unsafe query inputs, and schema-guard failures before any SQL reaches the database. Developers meet it as 'Undefined value encountered in property...' in find() filters, 'Dependency Cycle Found' at startup, 'was not found in table...' during migrations, and dozens of similar guard messages. This family covers the 334 documented TypeORMError records across the typeorm and n8n repositories and explains the shared mechanism behind them. (334 documented occurrences) - HTTPError: what it means when a library throws an "HTTPError" (and how to fix it)
"HTTPError" is the generic exception name many open-source libraries use to wrap any failed HTTP request — a non-2xx status, a failed retry loop, or an upstream service error rethrown in the library's own words. Developers meet it in Budibase, Bundler, yt-dlp, frp, and others whenever an HTTP call behind an SDK, importer, or fetcher fails and the library surfaces the failure as an HTTPError instead of a raw network exception. (332 documented occurrences) - UserError: Odoo's user-facing guard exception, and its Supabase and n8n variants
UserError is a deliberately thrown, user-facing exception that means an application-level guard rejected the operation: a business rule, compliance lock, registration conflict, or input validation fired on purpose, and it is not a bug or a crash. Developers meet it most often in Odoo (odoo.exceptions.UserError, raised by constraints, wizards, and Peppol/IAP proxy connectors), and as a small ApplicationError subclass in Supabase edge functions and n8n workflow code, where it surfaces as a translated dialog message, an HTTP 400 with a structured body, or a CLI error. (307 documented occurrences) - anyhow::Error — Rust context-wrapped failures and chained error messages, explained
anyhow::Error is the application-level error type Rust programs reach for when the result is meant for a human, not a match arm. It boxes any failure and lets developers attach readable context with .context(), bail!, and anyhow!, producing a chain whose top message is descriptive and whose bottom holds the root cause. Developers meet it across cargo, fd, rust-analyzer and coverage tooling, clash-verge-rev, ECC, and Turbopack whenever an operation fails and the program annotates rather than silently discards it. (284 documented occurrences) - InvalidDataException: when .NET data is malformed, truncated, or in the wrong format
InvalidDataException is a System.IO exception that .NET libraries throw when the content of a file, stream, or payload does not match the format the parser expected. Developers meet it when JSON will not deserialize, an XML document has no root element, a binary header's magic bytes are wrong, a cached artifact is from an incompatible version, or a downloaded file changed mid-transfer. Unlike IOException (which blames the channel) or ArgumentException (which blames the caller), InvalidDataException blames the data itself, so the fix is almost always to repair, regenerate, or replace the offending input rather than to retry the call. (278 documented occurrences) - IllegalStateException in Java: when a library rejects your call because the object or environment is in the wrong state
IllegalStateException is a Java runtime exception (unchecked, from java.lang) that libraries throw when a method is invoked at the wrong time, on an object in the wrong state, or in an environment that violates an invariant the code assumes holds. Across the ErrLookup family it appears as a raw, un-subtyped guard that almost always signals caller misuse or a broken deployment rather than malformed input data, and it frequently wraps an underlying checked exception (a JacksonException, IOException, NoSuchAlgorithmException, or reflective failure) whose caused-by carries the real root cause. (260 documented occurrences) - Hibernate MappingException: mapping errors that fail SessionFactory/EntityManagerFactory startup, explained
MappingException is the exception Hibernate ORM throws when the object-relational mapping itself is invalid, almost always while the SessionFactory or EntityManagerFactory is built, before any query runs. Developers meet it as a bootstrap crash naming an entity, property, or dialect: an embeddable mapped twice with different attributes, IDENTITY or SEQUENCE generation on a database that lacks it, contradictory annotations like @OptimisticLock(ALL) without @DynamicUpdate, malformed native-query result mappings, or legacy hbm.xml corners. This article covers the whole family, what each sub-group means, and the fixes that hold across it. (255 documented occurrences) - Rust io::Error: what ErrorKind::NotFound, PermissionDenied, and InvalidData actually mean — from real OS failures to library fail-closed refusals
io::Error is the error type Rust programs surface when input or output fails — a missing TLS certificate file, an unwritable temp directory, a truncated build archive, a rename blocked by a cloud-sync placeholder. This family covers both faces of the type across crates such as rustfs, rustc, cargo, Rocket, yazi, exa, and rustdesk: genuine OS errors (errno and Windows error codes mapped to ErrorKind) that libraries re-wrap with context, and library-minted errors built with io::Error::new to express fail-closed invariants such as reparse-point refusals, identity-change races, erasure-shard inconsistency, and framing violations. Developers meet it during file reads and writes, renames, canonicalization, TLS setup, archive building, and DRM capture; the same ErrorKind can be a raw OS verdict in one library and a deliberate refusal in another, so the message and library docs decide which. (252 documented occurrences) - FileNotFoundError in Python: missing model weights, config files, and paths that only look like file problems
FileNotFoundError is Python's built-in signal that a path expected on disk does not exist — but in practice it fires far beyond typos. Across the 249 documented records in this family, it most often appears when machine-learning weights were never downloaded (offline hosts, blocked egress to huggingface.co or modelscope.cn), when settings or .env files are absent at startup, when a renamed or mis-cased file defeats filename-based dispatch, or when a failed network fetch is wrapped and re-raised as this error even though no file was ever involved. Developers meet it on first run of a model, in air-gapped deployments, and in long training jobs whose dataset paths resolve against the wrong base directory. (249 documented occurrences) - EmptyResultError / "no results found": when an API or scraper succeeds but returns zero rows
EmptyResultError, "No tasks match the specified criteria", "no pins found", and similar "empty result set" errors are thrown when a request completes successfully — no network failure, no auth problem — but the returned data is an empty list: zero rows, zero items, zero messages. This page explains why libraries turn empty results into typed errors instead of returning [], what actually caused the emptiness, and how to handle it as an expected 'no data' outcome. (245 documented occurrences) - BadRequestException (HTTP 400) — NestJS 'Bad Request' Errors: Why They Fire and How to Fix Them
BadRequestException is the NestJS exception class that maps to HTTP 400 Bad Request, thrown when an incoming request is malformed, references a missing resource, violates a domain rule, or trips a security gate. Across cal.com, Hoppscotch, and Immich it is the most common client-side rejection a developer meets on POST/GET/PATCH calls — for input-validation failures, credential lookups, OAuth flow checks, and catch-all wrappers that re-throw upstream errors as a generic 400. Because the class carries only a free-text message, the same 400 status can mean anything from 'you sent a bad field' to 'the server swallowed an internal failure', so reading the message string and the surrounding logs is essential. (243 documented occurrences) - NodeOperationError in n8n: what the wrapped error means, and how to find the real cause behind it
NodeOperationError is n8n's standard error class for a node-level operation failure: almost every error raised inside a node's execute path — API rejections, validation failures, invalid router dispatches, exceeded limits — either is one or gets re-wrapped into one with the node name and itemIndex attached. You meet it when a workflow execution halts (or, with Continue On Fail enabled, when an item comes back with error output), and the message you see may be the original error's text, a rewritten friendlier version of it, or a generic wrapper. The records also show mem0 surfacing the same class for server config validation, so exact semantics are library-specific. (226 documented occurrences) - InvalidUserDataException: Gradle's invalid-user-data build failure — malformed notations, missing properties, and validation errors explained
InvalidUserDataException is the build-time error thrown when user-supplied input fails structural validation: malformed group:name:version or capability notations in useTarget(), useModule(), and dependency substitution; wrong version-catalog accessors; missing signing properties; colliding subproject accessor names; artifact transform outputs that are missing, absolute, or the wrong file/dir shape; and component metadata rules that assume variants the target does not publish. Elasticsearch's documentation build reuses the same class for REST-test snippet errors such as orphaned // TEST and // TESTRESPONSE markers, misplaced TESTSETUP directives, and response JSON that fails to parse. In every documented case the fix is to correct the build script, property, or snippet you wrote, not the tool. (223 documented occurrences) - NullPointerException ("x == null", "response == null", "scheduler == null"): Java null guards and accidental null dereferences explained
NullPointerException is the Java Virtual Machine's signal that code touched a null reference — but across open-source libraries, most documented NPEs with messages like "scheduler == null" or "response == null" are deliberate fail-fast guards thrown the instant you pass a null argument to a factory, builder, or constructor. Developers meet this family when a dependency-injected value was never bound, a config property resolved to null, a test mock returned null, or a required resource (script engine, database, file) was missing at runtime. This article explains how the guard pattern varies across Retrofit, RxJava, RxAndroid, Zipkin, Dubbo, Seata, Flink, ANTLR, Canal, and others, and how to tell a deliberate guard from a real bug. (219 documented occurrences) - InvalidParameterError: RSSHub HTTP 400 "invalid parameter" errors — why route parameter validation fails and how to fix it
InvalidParameterError is the validation error thrown by route handlers when a path parameter fails its guard: an unknown category, subsite, or sort key; a non-hostname-safe value where a subdomain is expected; a malformed composite type string; or a resource that does not exist. It serializes to an HTTP 400 response, so the caller sees a client-error status rather than a crash or a 500. This article maps the whole family across the RSSHub codebase: the validation patterns behind it, the most frequent triggers, the known dead-guard bugs that mask it, and the fixes that hold across routes. (210 documented occurrences) - FileNotFoundException: "could not find file" — missing assets, wrong paths, dead downloads, and stripped embedded resources
FileNotFoundException is thrown when code tries to open, read, or promote a file that does not exist at the resolved path. Developers meet it when a bundled asset is missing after install, a relative path resolves against the wrong working directory, a case-sensitive filesystem rejects a path that worked on Windows, an embedded resource was dropped by trimming, or a library maps an upstream HTTP 404 onto this exception. This article covers the family across 53 repositories: the layers that produce it, the causes that recur regardless of library, and the checks that prevent it. (204 documented occurrences) - Tensor shape mismatch errors ("must have shape", "expected shape ... got ..."): when tensor dimensions disagree with what an op or layer was told to expect
Tensor shape mismatch errors fire when a tensor's dimensions don't match a contract another component depends on — a kernel's expected strides, a layer's assumed model width, or metadata describing a batch. You meet them as ValueErrors naming expected and received shapes, raised by validation guards in attention kernels, multimodal preprocessors, quantization checkpoint checkers, CRF layers, and functional model call sites across libraries like SGLang, Keras, HanLP, and ruflo. They almost always mean two producers in the pipeline sized the same data differently, not that the math itself failed. (203 documented occurrences) - 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty
'Could not be found', 'does not exist', 'not found in database', 'not valid', 'not registered' — these errors fire when a library resolves a resource by an identifier you supplied and the lookup returns nothing. You meet them when a delete races your update, a slug or key is typo'd or miscased, the ID actually belongs to another database, user, or environment, or the resource is hidden by permissions or filters rather than truly absent. Across 200 documented records in 20 repositories, this article explains the mechanism, why the same miss surfaces as 400, 404, 500, a typed error code, or a CLI abort, and which fixes hold everywhere. (200 documented occurrences) - PHP \LogicException: the programmer-error exception — missing components, conflicting options, and misconfigured services that fail loud
PHP's \LogicException signals a fault in how code is written or configured — a missing optional dependency, mutually exclusive options, a service declared in a way the container cannot honour, or a precondition the caller skipped. Symfony, Laravel, Composer, and Guzzle all reach for it to refuse an operation outright instead of silently degrading, so when a developer meets it the fix is almost always at the call site or in configuration, not in retrying or waiting. (199 documented occurrences) - Python NotImplementedError: when a method, backend, or platform is deliberately unsupported
NotImplementedError is the signal Python libraries raise when a method exists on a type but does no real work in the current context. Developers meet it when they subclass a base class without overriding an abstract method, ask a database or result backend for a feature it structurally lacks, run on a platform missing a stdlib dependency, or push an unsupported node through a restricted query grammar. It is almost never a bug to patch around; it is a contract or capability boundary, and the fix is to choose a different method, backend, subclass, or platform rather than to force the call through. (198 documented occurrences) - AttributeError: module 'X' has no attribute 'Y' — what Python's missing-attribute error means across libraries
AttributeError: module 'x' has no attribute 'y' is the error Python raises when attribute lookup fails, and developers meet it most often importing from lazily-loaded packages (selenium.webdriver, vllm, litellm, scrapling, headroom.providers) where the name is misspelled, lives only in a submodule, or was renamed or removed in another release. The same exception class also enforces API rules — class-only pydantic metadata, read-only Selenium objects, unknown config fields — and can even wrap a missing dependency. Working out which of these you hit is the first step to the fix. (193 documented occurrences) - CommandError — when a CLI or management command stops cleanly with a message instead of a stack trace
CommandError is the exception that command-line tools and Django management commands raise when an invocation is invalid or cannot be completed: conflicting flags, a bad option value, a missing prerequisite, a name that will not work, or a wrapped failure from an external tool. A developer meets it at the terminal as a printed, human-readable message — often colored red and without a traceback — rather than as a crash. The same name, CommandError, is used by Django (the canonical source), pip, Expo, Alembic, and projects built on Django such as Plane, each raising it at the user-facing boundary to say the request itself is wrong, not that the program has a bug. (193 documented occurrences)
See it in action
opencode hits an AxiosError, asks the ErrLookup MCP server what it means, and applies the fix the library authors recommend.
Give your coding agent error superpowers
{
"mcpServers": {
"errlookup": {
"command": "npx",
"args": [
"-y",
"@standardbeagle/errlookup-mcp"
]
}
}
} The MCP server caches the dataset locally: offline-capable, no API keys, answers search_error straight from disk.