Error handling in most JavaScript and TypeScript codebases is a mess. Functions throw random exceptions, callers wrap everything in try-catch, and nobody knows what errors a function can actually produce. There’s a better pattern hiding in plain sight — and it comes from Rust.
<h2>The problem with exceptions</h2>
Exceptions are invisible in your function signatures. When you see this:
<pre><code class="language-typescript">async function getUser(id: string): Promise&lt;User&gt; {
 // ...
}
</code></pre>
You have no idea what can go wrong. It might throw a network error, a validation error, a “user not found” error, or a database connection timeout. The caller has to guess, and the guesses are usually wrong.
This leads to two anti-patterns:
1. The catch-all: Wrap everything in try-catch, log the error, return a generic “Something went wrong.” The actual error context is lost forever.
2. The catch-nothing: Don’t handle errors at all. Let them bubble up to some global handler that shows a toast. The user sees “An error occurred” with zero actionable information.
<h2>The Result type pattern</h2>
Instead of throwing, return a Result that explicitly represents success or failure:
<pre><code class="language-typescript">type Result&lt;T, E = Error&gt; =
 | { ok: true; value: T }
 | { ok: false; error: E };

async function getUser(id: string): Promise&lt;Result&lt;User, &#x27;NOT_FOUND&#x27; | &#x27;DB_ERROR&#x27;&gt;&gt; {
 try {
 const user = await db.users.find(id);
 if (!user) return { ok: false, error: &#x27;NOT_FOUND&#x27; };
 return { ok: true, value: user };
 } catch {
 return { ok: false, error: &#x27;DB_ERROR&#x27; };
 }
}
</code></pre>
Now the caller knows exactly what can go wrong — it’s in the type signature:
<pre><code class="language-typescript">const result = await getUser(&#x27;abc&#x27;);

if (!result.ok) {
 switch (result.error) {
 case &#x27;NOT_FOUND&#x27;: return res.status(404).json({ message: &#x27;User not found&#x27; });
 case &#x27;DB_ERROR&#x27;: return res.status(500).json({ message: &#x27;Database unavailable&#x27; });
 }
}

// TypeScript knows result.value is User here
console.log(result.value.name);
</code></pre>
<h2>Why this is better</h2>
Errors are visible. The function signature tells you what can fail. No more guessing.
The compiler helps you. TypeScript will warn if you don’t handle all error cases in a switch statement (with <code>--strict</code> and exhaustive checks).
No unexpected crashes. Nothing is thrown, so nothing can bubble up unhandled to crash your process or show a random error page.
Composability. You can chain Results, transform them, and combine them without nested try-catch blocks.
<h2>When to still use exceptions</h2>
Result types aren’t for everything. Use exceptions for truly exceptional situations — programming errors, assertion failures, things that should never happen if the code is correct. Use Results for expected failure modes — network errors, validation failures, “not found” responses.
The rule of thumb: if the caller is expected to handle the failure, use a Result. If the failure means there’s a bug, throw an exception.
<h2>Getting started</h2>
You don’t need a library. The type definition above is 4 lines. Start using it in one module, see how it feels, and expand from there. Your future self debugging a production issue at midnight will thank you.
Have you tried Result types in TypeScript? What was your experience?

sirajju

Exceptions in TypeScript hide failure modes from function signatures, leading to either catch-all handlers that lose context or unhandled errors that crash processes. The Result type pattern — borrowed from Rust — encodes success and failure directly in the return type, making all possible errors visible to callers and the TypeScript compiler. A minimal 4-line type definition enables exhaustive error handling via switch statements, eliminates unexpected throws, and improves composability. The pattern is best suited for expected failures like network errors or missing records, while true exceptions remain appropriate for programming bugs and assertion failures.

Stop Writing Try-Catch Everywhere — Use Result Types Instead

Switched my entire API layer to Result types last year and the improvement in error handling clarity was immediate. The biggest win: new team members could understand error flows just by reading function signatures instead of tracing through catch blocks.