You’re Doing Error-Handling Wrong!

You’re Doing Error-Handling Wrong: A Case for Predictable and Standardized Responses

Introduction: An Opinionated Stance

Error handling in JavaScript is a topic that evokes strong opinions, and I’m here to share mine: the traditional try-catch approach is clunky, inconvenient, and outdated. At Garmingo, where we built Garmingo Status — a SaaS solution for uptime and infrastructure monitoring—we’ve shifted away from try-catch blocks. Instead, we embraced a TypeScript-based approach that provides predictable, standardized responses for asynchronous operations.

This article shares why we believe this paradigm is a game-changer for developer productivity and how it helped simplify our codebase. While it’s an opinionated take, I hope it inspires you to rethink how you handle errors in your own projects.

The Problem with try-catch

Let’s face it: error handling in JavaScript can get messy. Traditional try-catch blocks come with a host of challenges:

1. Verbosity: Wrapping every asynchronous function call in a try-catch adds unnecessary boilerplate. It clutters your code and detracts from readability.
2. Inconsistent Error Objects: JavaScript error objects can vary wildly in structure and content. Without standardization, handling these errors often feels like playing a guessing game.
3. Nested Logic Hell: When dealing with multiple operations that can fail, nested try-catch blocks turn your code into an unreadable mess.

Here’s a simple example highlighting these issues:

try {
  const user = await fetchUser();
  try {
    const account = await fetchAccount(user.id);
    console.log(account);
  } catch (accountError) {
    console.error('Error fetching account:', accountError);
  }
} catch (userError) {
  console.error('Error fetching user:', userError);
}

The result? Code that’s harder to read, debug, and maintain.

Enter the TypeScript Typed Response Paradigm

At Garmingo Status, we ditched try-catch in favor of a standardized response structure for all asynchronous operations. Here’s how it works:

The Structure

Every async function returns a Promise with a predefined union type:

Promise<
  | { success: false; error: string }
  | { success: true; result: T }
>;

This approach ensures that:

• If the operation fails, the result is always { success: false, error: string }.
• If it succeeds, it’s { success: true, result: T }.
• If success is true there is a result object and no error object and vice versa. You cannot even use the result on failed responses.

Here’s the same example from above, rewritten with this pattern:

const userResponse = await fetchUser();

if (!userResponse.success) {
  console.error('Error fetching user:', userResponse.error);
  return;
}

const accountResponse = await fetchAccount(userResponse.result.id);

if (!accountResponse.success) {
  console.error('Error fetching account:', accountResponse.error);
  return;
}

console.log(accountResponse.result);

As you can see it does not introduce any nesting for the main logic of your app. It just adds these small checks for error handling, but the main flow remains uninterrupted and can continue like there was no need for error handling in the first place.

The Advantages of Predictable and Standardized Error Handling

1. Predictability

The biggest benefit is knowing exactly what to expect. Whether the operation succeeds or fails, the structure is consistent. This eliminates the ambiguity that often comes with error objects.

2. Ease of Use

Gone are the days of deeply nested try-catch blocks. With the typed approach, you can handle errors inline without breaking the flow of your code.

3. Improved Readability

The structured approach makes your code cleaner and easier to follow. Each operation clearly defines what happens in success and failure scenarios.

4. Enhanced Type Safety

TypeScript’s static analysis ensures you never forget to handle errors. If you accidentally omit a check for success, the TypeScript compiler will flag it.

A Balanced Perspective

No approach is without its drawbacks. The typed response paradigm requires you to explicitly check the success status for every operation, even if you’re confident it will succeed. This adds minor overhead compared to the traditional approach, where you might simply avoid error handling altogether (albeit at your own risk).

However, this “drawback” is also one of its strengths: it forces you to think critically about potential failures, resulting in more robust code.

How We Use It at Garmingo Status

At Garmingo, this approach has transformed how we build asynchronous utilities and libraries. Every API call and database query adheres to this standardized response structure, ensuring consistency across our codebase.
In fact, EVERY single async function that is reused trough-out the project and could fail uses this approach.
The result? A smoother (and much faster) development experience and fewer late-night debugging sessions.

For example, a fetch function could look like this:

async function fetchSomething(): Promise<
  | { success: false; error: string }
  | { success: true; result: Status }
> {
  try {
    const response = await api.get('https://exampleapi.com/');
    return { success: true, result: response.data };
  } catch (error) {
    return { success: false, error: 'Failed to fetch status' };
  }
}

This predictability has been a game-changer for our team, allowing us to focus on building features rather than untangling error-handling logic.

Conclusion

Traditional try-catch blocks have their place, but for modern JavaScript development — especially in TypeScript-heavy codebases — they’re often more trouble than they’re worth. By adopting a typed response paradigm, you gain predictability, readability, and peace of mind.

At Garmingo, we’ve seen firsthand how this approach simplifies development and enhances our ability to deliver a polished product like Garmingo Status. While it might not be for everyone, it’s an approach I strongly believe more developers should consider.

So, are you ready to rethink error handling? Let me know your thoughts!