Js error handling

Skill Amey-Thakur/AI-SKILLS/skills/javascript-typescript/js-error-handling

Plug-and-play skills and prompts for every AI coding agent

Install

npx -y skills add Amey-Thakur/AI-SKILLS --skill js-error-handling

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

18 days oldThe repository was created 18 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Handle errors in JavaScript and TypeScript with proper Error subclasses, cause chains, and a policy for async and unhandled failures. Use when designing error handling or debugging lost stack traces and swallowed errors.

SKILL.md

3.3 KB, as published. Nobody here has run it

JS error handling

JavaScript lets you throw anything and catch it as unknown, which is exactly how error handling goes wrong: strings thrown instead of Errors, catch (e) where e is any, and rejections that vanish. A deliberate policy makes failures visible and diagnosable.

Method

Throw Errors, never strings or objects. Only Error instances carry a stack trace and work with tooling. throw new Error("..."), never throw "failed". Subclass for distinct handling: class NotFoundError extends Error with a set name, so callers can branch on the type (instanceof) rather than string-matching messages.
Type the catch as unknown and narrow. In TypeScript, catch (e) gives unknown (with useUnknownInCatchVariables): you cannot assume e.message exists (someone threw a string). Narrow with e instanceof Error before touching properties, and have a fallback for the non-Error case (see typescript-narrowing).
Preserve context with the cause chain. When catching and re-throwing at a boundary, pass the original: throw new ConfigError("bad port", { cause: err }). The chain keeps the root cause and its stack, so the final log tells the whole story instead of a bare high-level message (see rust-error-handling for the same principle typed).
Catch narrowly, at the right level. Wrap the specific operation that can fail, not a whole function; catch where you can actually do something (retry, default, user message). A broad try around everything hides which call failed and catches errors you never meant to. Let genuinely unexpected errors propagate to a top-level handler.
Set a policy for async and unhandled failures. Every async entry point (route, event handler, job) has one place that catches and reports (see js-async-patterns). Register unhandledRejection / uncaughtException (Node) and window.onerror / unhandledrejection (browser) as backstops that log to your error tracker (see error-tracking): they should be near-empty in a healthy app, so treat hits as bugs.
Decide errors-vs-results deliberately. For expected failure that callers routinely handle (validation, "not found"), a result type ({ ok: true, value } | { ok: false, error }) or returning null/undefined can be clearer than throwing; reserve exceptions for the exceptional. Whatever you choose, be consistent within a module.

Boundaries