No more Try/Catch: a better way to handle errors in TypeScript

It is bad design, it is like going back from exception to C style (error, result) returns.

If this pattern was useful, exceptions would never be invented.

When you nest your code, you need to rethrow the error as method has failed and result is undefined.

Such code will lead to nightmare as one will not be able to find out why result is invalid and error is not thrown. Console log doesn’t help for caller.

Exceptions were invented in such a way that top caller can catch it, log it and process it. There is no point in changing the calling sequence and rewrite same logic again to virtually invent new throw catch.

This is an interesting idea. But over my many years of coding, I find try catch very useful… some might disagree but I kinda see it as an advantage to other languages… maybe more like the panic in Go.

In my use cases, my apps never break, errors are handled elegantly, proper notifications are resolved… although, I use this pattern even in TS and haven’t come across any blockers.

But for sure I can try your idea and refine it but it would most likely complement the try catch syntax and advantages rather than replacing it.

I like the syntax that it creates and the inspiration from Golang and the ?= syntax that has recently been proposed and is in very early stage.

I do wonder about how much benefit this has since you now have to have 2 conditions where the error is handled, one in the catch block and one in the if block.

If you are wanting to suppress the error but still add a log of some sort, you can simply use a combination of await / catch

const user = await getUser().catch((err) => {
  console.log(err)
}) 

This is less code and allows you to avoid using let

I don't quite see the advantage of this over using

const user = await getUser(1).catch(console.log);

In what cases is your suggestion better?

This is a great breakdown of the limitations of try/catch and a more elegant solution for handling errors in TypeScript. The catchError function looks incredibly useful for maintaining clean and readable code.

there is no problem with try catch and your suggested "solution" is actually looks more like a hack ... why not make typed catch ?? like it is in java that way you can catch exactly the error you need to .. is not typescript all
about being "typed" javascript anyways ???

Instead of combining the worst of two, embrace Result type (also known as Either). Return your errors explicitly, handle them explicitly, don't throw exceptions.

Promise type is close to it, but unnecessarily combines Future with Result. Conceptually, both should have been independent, and Promise would've been Future> - e.g. a value that might eventually become a success or an error.

Then you'd await it to get Result, and pattern-match the Result to handle your error. It also removes the possibility of accidental error.

So we're back at good old Nodejs style error handling? Although this might solve a few issues, it feels for me like it goes only half way in the right direction. While the article explains well some issues with try catch, it actually doesn't offer a solution and only a half-way mitigation, because in the end, instead of having no idea about which error hits youin the catch block, you now have no idea which error hit you in the first array element. I also think, using a tagged result object (like { ok: true, data: T } | { ok: false, error: E }) is a bit nicer here, as it offers some more room for extensions on the result object.

Personally, I am satisfied with native JS try/catch implementation over abstraction. However, yours feels like a step backward, remember the good old callbacks that got the error and response as arguments? Either way, I believe there are better ways to handle your problems:

1) Move the try/catch to the appropriate location, rather than a chain of try/catches, and let the control flow take care of things for you.

const getUser = async (id) => {
  try {
    const response = await fetch(`/user/${id}`)

    if (!response.ok) {
      return [new Error(`Failed to fetch user. got status: ${response.status}`), null]
      // new Error to create call stack
      // return, not throw
    }

    const user = await response.json();

    return [null, user];     // return, not assign
  } catch (error) {
    return [error, null];    // error!
  }
}

const [error, user] = await getUser(); // assign here

2) Don't want to have response checks everywhere? I am not talking about the fetch specifically, but more of the pattern in general. It is better to move those further upstream with meaningful abstraction.

const jsonFetch = (...args) => {
  const response = await fetch(...args); // passthrough

  if (!response.ok) {
     throw new Error(`Failed to fetch user. got status: ${response.status}`);
     // why not return? I classify this as a system utility, and I would rather
     // keep it a consistent behaviour. So, no try/catch, no return, but throw.
  }

  return response.json();
}

const getUser = async (id) => {
  try {
    const user= await jsonFetch(`/user/${id}`);
    // simpler, meaningful, same as existing code
    return [null, user];
  } catch (error) {
    return [error, null];
  }
}

3) Building on, we can also do more of a utilitarian approach (for the try/catch haters out there):

// const jsonFetch

const tuplefySuccess = (response) => [null, response];
const tuplefyError = (error) => [error, null];

const [error, user] = await getUser()
  .then(tuplefySuccess)
  .catch(tuplefyError);

// OR

const [error, user] = await getUser().then(tuplefySuccess, tuplefyError);

// OR

const tuplefy = [tuplefySuccess, tuplefyError];

const [error, user] = await getUser().then(...tuplefy); // TADA!

4) Finally, modularize!

// json-fetch.js
export const jsonFetch = (...args) => { /* ... */ };  // abstraction of related code

// tuplefy.js
export const tuplefy = [...];  // utilities

// user.js
const getUser = (id) => jsonFetch(`/users/${id}`);
const [error, user] = await getUser(1).then(...tuplefy);   // Implementation

With this, you are still following modern javascript sugars, meaningful abstraction, less cognitive overload, less error-prone, zero try/catch, etc. This is my code style. If you were on my team, you really don't want try/catch, and I was reviewing your PR for this utility, this is how I would have suggested you write the code. I'd greatly appreciate it if you could look at my suggestion as a pattern rather than an answer to the specific problems you presented. I welcome other devs to suggest different styles or improvements to my code as well. ❣️Javascript!

Great article. Thanks for elaborating on this topic. The try/catch format has limitations and introduces more clutter. I myself also faced the same problem in PHP. In my concept, I implemented Result type from Rust to return either an error or a value.

dev.to/crusty0gphr/resultt-e-type-...