The try/catch block is a staple of JavaScript, but it leaves a lot to be desired (especially when working with TypeScript). None of the errors are typed, it adds an extra level of block scoping which can make certain code difficult to write, and it catches all errors (not just the ones you want). That is why in this video I will show you 3 alternatives to try/catch that I much prefer.


🌎 Find Me Here:

My Blog: https://blog.webdevsimplified.com
My Courses: https://courses.webdevsimplified.com
Patreon: https://www.patreon.com/WebDevSimplified
Twitter: https://twitter.com/DevSimplified
Discord: https://discord.gg/7StTjnR
GitHub: https://github.com/WebDevSimplified
CodePen: https://codepen.io/WebDevSimplified


⏱️ Timestamps:

00:00 - Introduction
00:24 - Starting Code
01:12 - Bad Error Handling
03:36 - Basic Fix
06:11 - Advanced Fix


#ErrorHandling #WDS #TypeScript

Web Dev Simplified

Handling errors in JavaScript using try/catch can lead to issues with code organization and unexpected error handling. This guide explores alternative methods, including a custom function to return arrays of errors and successful states. It introduces advanced concepts like custom errors and references the Effect library for sophisticated error handling.

I'm Ditching Try/Catch for Good!

I’ve compiled all the information and asked ChatGPT to write a report to help us understand the pros and cons based on community comments.
And it’s worth remembering that we have this proposal going on: 
<a href="https://dev.to/dharamgfx/bye-bye-try-catch-blocks-meet-javascripts-safe-assignment-operator-proposal-1j7?ref=dailydev" target="_blank" rel="noopener nofollow">https://dev.to/dharamgfx/bye-bye-try-catch-blocks-meet-javascripts-safe-assignment-operator-proposal-1j7?ref=dailydev</a>
<h2>Final Report on <code>catchErrorTyped</code> Implementation and Whether to Ditch Try/Catch</h2>
The concept of ditching <code>try/catch</code> in favor of a <code>catchErrorTyped</code> function, which is inspired by Go’s error-handling pattern, has sparked a lot of debate within the developer community. Let’s break down the primary points from the feedback to evaluate the pros and cons of this approach.
<h3>Pros of the <code>catchErrorTyped</code> Approach:</h3>
<h4>Clear Error Handling:</h4>
Many developers find this approach more explicit, as it returns a tuple (<code>[error, result]</code>), which makes it clear that both error and result are possible outcomes of the asynchronous operation. This is a familiar pattern for Go developers, and some have adopted it into TypeScript and JavaScript ecosystems because it simplifies flow control in certain cases.
Comment Example: 
@mohammadahmermalick7869: “This really helped me out. It’s inspired by Go, and I like the structured handling of errors.”
<h4>Declarative Control Flow:</h4>
The code flow feels less fragmented, as there is no need to nest the business logic within a <code>try</code> block, followed by error handling in a <code>catch</code> block. It encourages separating the success case from the error-handling code in a clean and structured manner.
Comment Example: 
@amineabdz: “It makes the flow of logic easier to write without try/catch.”
<h4>Cleaner Logic in Some Cases:</h4>
Developers often point out that when handling specific error types, this method provides a cleaner syntax than embedding the logic within multiple <code>try/catch</code> blocks. The logic for handling specific errors can be isolated and processed as necessary.
Comment Example: 
@nobodysaysmynameright: “This method mirrors Go’s approach, which works well to avoid nested try/catch blocks in large codebases.”
<hr>
<h3>Cons of Ditching <code>Try/Catch</code>:</h3>
<h4>Non-Idiomatic for JavaScript/TypeScript:</h4>
Many argue that <code>catchErrorTyped</code> forces Go-like error handling into a language that already has built-in error handling. JavaScript and TypeScript developers are more familiar with the traditional <code>try/catch</code> block, and deviating from this can lead to confusion and inconsistent implementations across a codebase.
Comment Example: 
@chris94kennedy: “Forcing Go idioms into TypeScript doesn’t always make sense. It risks inconsistent implementation, and using native error-handling patterns is generally more predictable.”
<h4>Readability Issues:</h4>
Several commenters find this new approach harder to read. While it simplifies error checking in some cases, it introduces tuples that require the developer to manage multiple return values. This can clutter the code, especially if the error types aren’t easily distinguishable, leading to confusion.
Comment Example: 
@jeroenplayak2433: “Try/catch is definitely less obscure to read.” 
@pineappl3pizzzasoju: “There should have been proper error handling in the getUser function itself. That would have solved the problem.”
<h4>Performance Concerns:</h4>
Using tuples or arrays to return both results and errors introduces extra allocations in memory, which could lead to unnecessary overhead. This pattern might not be ideal for performance-critical applications or code that makes heavy use of promises.
Comment Example: 
@tanishqmanuja: “Allocation of countless extra arrays 😢”
<h4>Complexity with Larger Codebases:</h4>
While the tuple approach works well for small functions, in larger codebases, managing multiple error-returning functions this way could get messy. This requires handling different error types and maintaining consistency across the project.
Comment Example: 
@AdamsTaiwan: “Wrapping every method this way may look messy. I still prefer try/catch with the catch calling a global error handler/logger.”
<h4>Misuse or Overcomplication:</h4>
Some argue that this approach might be overcomplicating a problem that is already well-handled by <code>try/catch</code>. Instead of introducing new patterns, improving how <code>try/catch</code> is used (like rethrowing errors or better organization) could yield better results without adding complexity.
Comment Example: 
@AbsoluteWoo: “This video should actually be titled ‘I don’t understand how to use try/catch properly’.”
<hr>
<h3>Neutral or Context-Dependent Insights:</h3>
<h4>Specific Use Cases:</h4>
There is a consensus that this approach works better in specific scenarios, such as with tools like React Query or Supabase, which return results and errors in a more structured form. However, it’s not universally applicable and should be used with care.
Comment Example: 
@gasparsigma: “This is useful in an abstraction like your react-query fetcher that can give you the data or handle the error headers/body for you. For everything else, try/catch is easier to read.”
<h4>Libraries like <code>Effect</code> or <code>Neverthrow</code>:</h4>
Some developers suggest that if this kind of structured error-handling approach is desired, it might be better to use established libraries like <code>Effect</code> or <code>neverthrow</code> that provide safer abstractions and integrate error handling more naturally.
Comment Example: 
@TannerBarcelos: “I fell in love with this approach in Go. So glad this is being adopted into the TypeScript ecosystem. It makes so much sense.”
<hr>
<h3>Conclusion:</h3>
<ul>
<li>
Keep <code>Try/Catch</code> as the Default: The feedback suggests that for most developers and projects, the native <code>try/catch</code> block remains the simplest, most predictable, and idiomatic way to handle errors in JavaScript/TypeScript. It integrates well with the existing patterns of the language and has better readability for most developers.
</li>
<li>
Use <code>catchErrorTyped</code> Sparingly: The <code>catchErrorTyped</code> approach is beneficial in certain situations, particularly when handling specific types of errors (e.g., custom errors) or when working in environments where errors are treated as values (e.g., Go-inspired patterns). However, it can lead to code complexity, especially in large codebases or performance-sensitive applications. It might be more appropriate for certain projects (e.g., React Query or Golang-inspired architectures) but should be avoided as a general-purpose error-handling strategy.
</li>
</ul>
In short, **don’t fully ditch <code>try/catch**—use it as your default, and apply </code>catchErrorTyped` or similar approaches in targeted scenarios where it provides clear value.

catchErrorTyped Function
<pre><code>function catchErrorTyped&lt;T, E extends new (message?: string) =&gt; Error&gt;(
 promise: Promise&lt;T&gt;,
 errorsToCatch?: E[]
): Promise&lt;[undefined, T] | [InstanceType&lt;E&gt;]&gt; {
 return promise
 .then(data =&gt; {
 return [undefined, data] as [undefined, T];
 })
 .catch(error =&gt; {
 if (errorsToCatch === undefined) {
 return [error];
 }

 if (errorsToCatch.some(e =&gt; error instanceof e)) {
 return [error];
 }

 throw error;
 });
}
</code></pre>
Define a custom error:
<pre><code>class CustomError extends Error {
 name = &quot;CustomError&quot;;
 extraProp = &quot;ERROR: test&quot;;
}
</code></pre>
Use the catchErrorTyped function with custom errors:
<pre><code>const [error, user] = await catchErrorTyped(getUser(2), [CustomError]);

if (error) {
 console.log(&quot;There was an error:&quot;, error.message);
} else {
 // Handle the user data
 console.log(user);
}
</code></pre>

It seems very controversial, looking through the YT comment timeline.
Consider with care.

Am I wrong, or does this pattern resemble error handling in Go? In any case, interesting approach!

It is funny how this is almost taking you back to the old days of callbacks. I just don’t see issues with nesting but this would be great functions to have and a very functional way to handle errors. Also I don’t understand the logic around not wanting to install libraries because they are massive. Front-ends use tree shaking to remove all the code you don’t call and backend Node.js it really isn’t that big of a deal.
One issue is JavaScript you can throw non Error types so the types could be wrong, especially if the error was thrown in a third part library.