← All Articles

Error Message FAQ: Quick Answers to the Questions in the Error

At a Glance
Not sure where to start with an errorWant to find the right guide fastBuilding error handling from scratch

An error is a message from the runtime about a contract violation. Everything you need to fix it is usually in the message itself — this page is the map to reading it.

The Universal First Questions

Is this error actually an error?

Some "errors" are information: git's "nothing to commit, working tree clean", HTTP 304 Not Modified, npm's "up to date" messages. Check whether anything is actually broken before debugging a non-problem.

Who is responsible — my code or the platform?

HTTP gives the cleanest split: 4xx = request problem (caller side), 5xx = server problem. Most other systems have an equivalent: compile errors = your code, runtime framework errors = contract mismatch, network errors = infrastructure or configuration. Knowing the side halves the search space instantly. Status code guide.

What changed?

The most useful question in all of debugging. It worked yesterday: what shipped, what dependency updated, what data changed, what config rotated? git log --since=yesterday in your repo and a glance at the dependency lockfile diff usually answer it before any code reading does.

Reading Errors by Family

Null / undefined family

"Cannot read properties of undefined", NullPointerException, NullReferenceException, AttributeError on NoneType, Go nil panic — all one bug shape: a value was absent where the code assumed presence. The fix pattern is identical everywhere: find WHY it's absent (upstream lookup, missing default, failed prior step) and decide: guard at use, or guarantee at source. Language guides: JS · C# · Python · Go.

Type mismatch family

Expected X, found Y; TypeError: not a function; ClassCastException — the value flowing through your code is not the type the code requires. Trace the value back to its source; the bug is where it was produced or where the contract changed, not where it was used. Guides: TypeScript · JS not-a-function · Java.

Connection family

ECONNREFUSED, timeout, TLS errors, 502/504 — the message tells you which layer failed (DNS, TCP, TLS, HTTP), and the fix follows the layer: DNS → resolution/config, TCP → is anything listening, TLS → certificates, HTTP → status codes. Guides: ECONNREFUSED · SSL verify failed · EADDRINUSE.

Resource family

Permission denied, disk full, exit code 137, too many open files — the resource exists conceptually but access/space/limit failed. Check ownership before sudo, space before retries, limits before optimizing. Guides: Permission denied · Docker errors.

The Questions Developers Ask Most

Why does it work in Postman/curl but fail in my app?

Because the app sends different bytes: a header Postman added automatically (Content-Type, Origin), cookies the browser enforces, or a redirect the client follows differently. Capture both requests and diff them field by field — the difference is the bug. CORS guide for the browser-specific version.

Why does it fail in production but not locally?

Four suspects, check in order: environment variables (present locally via .env, missing in prod), data (prod has the edge case your seed data doesn't), scale (it's the same bug, just slow enough to time out), and platform differences (case-sensitive filesystem, different TLS versions). Production-fails-locally-works is a checklist, not a mystery.

How do I debug an intermittent error?

Intermittent = conditional: find the condition. Log correlation IDs and compare a failing request against a succeeding one — the differing field is the trigger. Common conditions: concurrency (lock contention, race), time (cache expiry, cron overlap, DST), and data (one specific user's record). Debugging workflow.

Should I catch this error or let it crash?

Catch when you can do something meaningful: retry, fallback, translate to a user-facing message. Let it propagate when the only correct response is "this is a bug" — empty catches convert loud bugs into silent corruption. When you catch, log with context or rethrow with from/cause — never both swallow and continue silently.

How do I write a good error message?

Three parts: what failed, with what value, and what to do. "JWT_SECRET is required; set it in .env" beats "config error" forever. The test: could someone fix the problem from the message alone, without reading the source? That is the bar your future self deserves.

When the Error Message Is Useless

Some messages hide the cause by design: 500 responses, "An unexpected error occurred", minified production traces. The recovery path: find the underlying log (server logs for 500s, source maps for minified JS), or reproduce with verbose mode (curl -v, npm install --loglevel verbose, framework debug flags). If the platform truly gives you nothing, binary-search your own code: disable half, does it still fail? The cause is in the failing half — that is bisection as a fallback, and it always works.

The Guides by Language

Python · JavaScript · Java · Rust · TypeScript · Docker · Git

Related Errors

How to read stack traces · Error prevention checklist · Systematic debugging workflow