Javascript

Problematic Try-Catches in JavaScript

Published Sep 14, 2020

Updated Feb 14, 2023

5 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Problematic Try-Catches in JavaScript

The try-catch syntax is a fundamental feature in most programming languages. It allows us to gracefully handle errors that are thrown in our code, and they do so in a way that is familiar to all programmers.

With that in mind, I'm going to propose that they are also highly misused and have a huge impact on the future maintainability of our codebases, not to mention, force us to sometimes implement error-prone code.

The beauty of using the standard try-catch syntax is that if we come back to a section of our code using try-catch, we immediately know that something in this block of code may throw an error, and we want to ensure that our application doesn't fall over because of it.

Reading the following block of code, we should get the general understanding of what is happening:

try {
  const result = performSomeLogic();
  const mutatedResult = transformTheResult(result);
} catch (error) {
  if (!production) {
    console.error(error);
  } else {
    errorMonitoringService.reportError(error);
  }
}

We can see that the block of code will perform some logic to get a result, then it will mutate that result. On error, it will log the error to the appropriate location.

So what's the problem? 🤔

Or rather, what are the problems? Let's look at each in turn!

1. Which method is throwing the error?

If we come back to refactor this block of code, we can't tell simply by looking at each method call in the try block which method may throw.
Is it performSomeLogic() or is it transformTheResult(result)?

To figure this out, we'll need to find where these functions are defined and read through their source to understand which one could potentially throw an error.

Is the function from a third-party library? In that case, we're going to have to go and find documentation on the function, hoping that the docs for the version we are using are still available online, to figure out which function could throw the error.

THIS IS PROBLEMATIC

It's adding additional time and complexity to understand the section of code, reducing its future maintainability. Refactoring or fixing bugs in this area is more complex already!

2. What if both methods should throw?

Here comes a new problem! When both performSomeLogic() and transformTheResult(result) are expected to throw, the catch block does not provide a convenient way to differentiate which threw:

try {
  const result = performSomeLogic();
  const mutatedResult = transformTheResult(result);
} catch (error) {
  // Did performSomeLogic or transformTheResult throw?
  // How can we find out?
}

So, now that both could throw, how do we find out which threw, in the case that we need to handle the errors differently? Do we inspect the error message?

try {
  const result = performSomeLogic();
  const mutatedResult = transformTheResult(result);
} catch (error) {
  if (error.message.includes("performSomeLogic")) {
    // Do error handling specific to performSomeLogic
  } else {
    // Do error handling specific to transformTheResult
  }
}

THIS IS PROBLEMATIC

Now we're coupling our code to an error message, which could change over time, not to mention increasing the difficulty in testing this section of code. There's now two branches here we need to test.

Any developer coming to this section of code to maintain it has to ensure that they take into account the differences in error messages to ensure the errors are handled appropriately.

3. I need to use `mutatedResult` for another action

Unsurprisingly you may have to use the result you get from a function that could throw to perform another action, similar to the code above where result was used to calculate mutatedResult.

Let's say you now need to call a new function updateModelViaApi(mutatedResult). Where do you put it?

Inside the try-catch after you calculate the mutated result?

try {
  const result = performSomeLogic();
  const mutatedResult = transformTheResult(result);
  const response = updateModelViaApi(mutatedResult)
} catch (error) {
  if (!production) {
    console.error(error);
  } else {
    errorMonitoringService.reportError(error);
  }
}

Surely not. You're only putting it there because you need access to mutatedResult which is within the try scope. If you then had to perform more logic with the response object, would you also put that into the try block?

try {
  const result = performSomeLogic();
  const mutatedResult = transformTheResult(result);
  const response = updateModelViaApi(mutatedResult)

  if(response.status === 200) {
      letsDoSomethingElse();
  }
} catch (error) {
  if (!production) {
    console.error(error);
  } else {
    errorMonitoringService.reportError(error);
  }
}

THIS IS PROBLEMATIC

Ok, our try block is continuing to grow, and going back to point 1, we are making it more and more difficult to understand what our try block is actually doing and further obscuring which function call we are expecting to throw. It also becomes much more difficult to test and more difficult to reason about in the future!

Could we not just move the variable outside the try scope? We could:

let mutatedResult;
try {
  const result = performSomeLogic();
  mutatedResult = transformTheResult(result);
} catch (error) {
  if (!production) {
    console.error(error);
  } else {
    errorMonitoringService.reportError(error);
  }
}

const response = updateModelViaApi(mutatedResult)

if (response.status === 200) {
  letsDoSomethingElse();
}

However, while this does reduce the amount of code in the try block, it still presents us with an issue of future maintainability, as well as a potential bug. We've declared a variable outside our try scope, without assigning it a value.

If an error is thrown before mutatedResult is set, execution will continue and our updateModelViaApi(mutatedResult) will be called with undefined, potentially causing another issue to debug and manage!

We see problems, but what's the solution? 🔥

To fully understand how to solve the problems presented, it's important to understand the goal of the try-catch syntax.

Try-catch allows the developer to execute throwable code in an environment where we can gracefully handle the error.

With this in mind, we have to understand that the implementation of this syntax by the language is essentially what creates these issues. If we look at the example above where we moved mutatedState outside the try scope, we solve an issue, but by doing this we break the functional programming concept of immutable state.

If we think of the try-catch block as a function, then we can see this breach of immutable state much clearer:

let mutatedResult;
tryCatch();
// expect mutatedState to now have a value
const response = updateModelViaApi(mutatedState);

However, by considering the try-catch block as a function, we can eliminate the problems we talked about earlier.

Having the try-catch logic moved into a function, we:

create a consistent pattern of running only the throwable code (Point 1)
can handle multiple throwable function calls and handle their individual errors explicitly (Point 2)
don't have to worry about block-scoped variables (Point 3)

So how do we transform the try-catch into a function?

Introducing no-try! 🚀

Luckily we don't have to. There is already a library that has done this for us.
NOTE: It should be noted this is a library I wrote

The library is called no-try and you can read more about it here. It will work in a browser environment as well as a node environment.

So what does no-try let us achieve?

Let's jump back to our first example and see if we can tackle the problem of Point 1 and refactor it to use no-try.

const { useTry } = require('no-try');
// You can also use 
// import { useTry } from 'no-try';

const [error, result] = useTry(() => performSomeLogic());

if (error) {
    console.error(error);
}

const mutatedResult = transformTheResult(result);

We can now see exactly which method we expect to throw an error, making it easier for any developer coming along afterwards to refactor this logic if they need to.

Admittedly, there's a slight cognitive load added to understand what useTry is, as it's not as immediately recognisable as a try-catch but from the naming and the usage, it should be pretty self-explanatory.

Can we also solve Point 2? Individually and explicitly handling errors thrown by multiple throwable function calls? Well, yes!

const { useTry } = require('no-try');

const [error, result] = useTry(() => performSomeLogic());

if (error) {
    console.error(error);
}

const [transformError, mutatedResult] = useTry(() => transformTheResult(result));

if (transformError) {
    notificationService.showError(transformError);
}

Now we can see that both methods may throw an error. We can handle both of these errors individually and without having to write code to figure out which error we're handling, reducing future maintenance.

Finally, tackling Point 3 should now be fairly straight forward. We don't have to worry about block-scoped variables or a try-catch block that's getting bigger and bigger as we need to execute business logic. If an error is thrown, we can exit the function before running code that might rely on a successful outcome:

const { useTry } = require('no-try');

const [error, result] = useTry(() => performSomeLogic());

if (error) {
    console.error(error);
    return;
}

const mutatedResult = transformTheResult(result);
const response = updateModelViaApi(mutatedState); 

if (response.status === 200) {
  letsDoSomethingElse();
}

This is much easier to reason about and it's straightforward to read. We can see what is expected to throw an error, where it is handled, and we aren't placing unnecessary code inside the try-catch block due to limitations presented by the language itself.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Colum Ferry
JavaScript Developer and Enthusiast. Really enjoy working with Angular. Married with 2 amazing kids. Powered by Coffee.
@FerryColum @https://github.com/coly010

Learning Paths for Next.JS Developers with Ankita Kulkarni

In this video, Rob Ocel and co-hosts Tracy Lee, Adam Rackis, and Danny Thompson talk with tech educator Ankita Kulkarni about her journey from engineering leader to full-time educator. Ankita shares insights on teaching Next.js, bridging practical knowledge gaps, and helping developers tackle real-world challenges. They discuss Next.js as a React-based framework, its benefits, and the challenges it presents for beginners. Chapters - Introduction to the Podcast and Guests 00:01 - Meet Ankita Kulkarni, Tech Educator 00:26 - Ankita's Transition to Full-Time Education 01:41 - Teaching Practical Knowledge in Next.js 03:19 - Effective Methods for Teaching Next.js 05:27 - Challenges of Being a Full-Time Educator 07:48 - Balancing Broad and Specific Examples 09:54 - Embracing Mistakes as a Teaching Tool 12:13 - Pair Programming and Mentorship 14:00 - Discussion on Next.js and Framework Adoption 16:48 - Advantages and Challenges of Next.js 18:12 - Choosing the Right Framework for Your Needs 20:35 - Impact of Next.js in React Documentation 22:26 - Learning Paths for New Developers 23:24 - The Rise of Full-Stack Web Development 25:09 - Benefits of Frameworks Abstracting Complexity 26:27 - OpenNext and Deployment Flexibility 28:06 - Ankita's Excitement for New Next.js Features 30:35 - The Future of Next.js Without Vercel 32:16 - Final Thoughts and Where to Find Everyone Online 34:21 Follow Ankita Kulkarni on Social Media Twitter: https://x.com/kulkarniankita9 YouTube: https://www.youtube.com/@kulkarniankita Sponsored by This Dot: thisdot.co...

Nov 12, 2024

2 mins

NextJSJavaScript

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

The HTML Dialog Element: Enhancing Accessibility and Ease of Use Dialogs are a common component added to applications, whether on the web or in native applications. Traditionally there has not been a standard way of implementing these on the web, resulting in many ad-hoc implementations that don’t act consistently across different web applications. Often, commonly expected features are missing from dialogs due to the complexity of implementing them. However, web browsers now offer a standard dialog element. Why use the dialog element? The native dialog element streamlines the implementation of dialogs, modals, and other kinds of non-modal dialogs. It does this by implementing many of the features needed by dialogs for you that are already baked into the browser. This is helpful as it reduces the burden on the developer when making their applications accessible by ensuring that user expectations concerning interaction are met, and it can also potentially simplify the implementation of dialogs in general. Basic usage Adding a dialog using the new tag can be achieved with just a few lines of code. ` However, adding the dialog alone won’t do anything to the page. It will show up only once you call the .showModal() method against it. ` Then if you want to close it you can call the .close() method on the dialog, or press the escape key to close it, just like most other modals work. Also, note how a backdrop appears that darkens the rest of the page and prevents you from interacting with it. Neat! Accessibility and focus management Correctly handling focus is important when making your web applications accessible to all users. Typically you have to move the current focus to the active dialog when showing them, but with the dialog element that’s done for you. By default, the focus will be set on the first focusable element in the dialog. You can optionally change which element receives focus first by setting the autofocus attribute on the element you want the focus to start on, as seen in the previous example where that attribute was added to the close element. Using the .showModal() method to open the dialog also implicitly adds the dialog ARIA role to the dialog element. This helps screen readers understand that a modal has appeared and the screen so it can act accordingly. Adding forms to dialogs Forms can also be added to dialogs, and there’s even a special method value for them. If you add a element with the method set to dialog then the form will have some different behaviors that differ from the standard get and post form methods. First off, no external HTTP request will be made with this new method. What will happen instead is that when the form gets submitted, the returnValue property on the form element will be set to the value of the submit button in the form. So given this example form: ` The form element with the example-form id will have its returnValue set to Submit. In addition to that, the dialog will close immediately after the submit event is done being handled, though not before automatic form validation is done. If this fails then the invalid event will be emitted. You may have already noticed one caveat to all of this. You might not want the form to close automatically when the submit handler is done running. If you perform an asynchronous request with an API or server you may want to wait for a response and show any errors that occur before dismissing the dialog. In this case, you can call event.preventDefault() in the submit event listener like so: ` Once your desired response comes back from the server, you can close it manually by using the .close() method on the dialog. Enhancing the backdrop The backdrop behind the dialog is a mostly translucent gray background by default. However, that backdrop is fully customizable using the ::backdrop pseudo-element. With it, you can set a background-color to any value you want, including gradients, images, etc. You may also want to make clicking the backdrop dismiss the modal, as this is a commonly implemented feature of them. By default, the <dialog> element doesn’t do this for us. There are a couple of changes that we can make to the dialog to get this working. First, an event listener is needed so that we know when the user clicks away from the dialog. ` Alone this event listener looks strange. It appears to dismiss the dialog whenever the dialog is clicked, not the backdrop. That’s the opposite of what we want to do. Unfortunately, you cannot listen for a click event on the backdrop as it is considered to be part of the dialog itself. Adding this event listener by itself will effectively make clicking anywhere on the page dismiss the dialog. To correct for this we need to wrap the contents of the dialog content with another element that will effectively mask the dialog and receive the click instead. A simple element can do! ` Even this isn’t perfect though as the contents of the div may have elements with margins in them that will push the div down, resulting in clicks close to the edges of the dialog to dismiss it. This can be resolved by adding a couple of styles the the wrapping div that will make the margin stay contained within the wrapper element. The dialog element itself also has some default padding that will exacerbate this issue. ` The wrapping div can be made into an inline-block element to contain the margin, and by moving the padding from the parent dialog to the wrapper, clicks made in the padded portions of the dialog will now interact with the wrapper element instead ensuring it won’t be dismissed. Conclusion Using the dialog element offers significant advantages for creating dialogs and modals by simplifying implementation with reasonable default behavior, enhancing accessibility for users that need assistive technologies such as screen readers by using automatic ARIA role assignment, tailored support for form elements, and flexible styling options....

Oct 25, 2024

4 mins

HTMLJavaScript

Migrating AngularJS to Angular

Introduction There is still a lot of confusion around Angular and AngularJS. It has gotten better, but searching for "Angular" still provides ambiguous results. This is a problem because AngularJS is on Long Term Support (LTS) mode. It entered LTS on July 1, 2018, for 3 years. It was granted a six-month extension due to COVID-19. Therefore, all support is expected to end on December 31, 2021, meaning Google will stop fixing bugs and providing support for AngularJS. All Angular engineering effort will be focused on the latest version of Angular making it prudent that active AngularJS codebases are migrated to Angular this year. This article will showcase different migration paths available to achieve this. Big Bang Rewrite By far, the easiest way to migrate a legacy codebase is to simply start fresh from the ground up. You won't have to worry about conflicting packages or supporting different versions of the same package. You would simply use the latest Angular CLI to scaffold out a new app and begin working on re-implementing your legacy app features with Angular. However, this is a significant engineering effort. This approach is excellent for very small AngularJS apps. However, it can also be possible for larger codebases. For larger codebases, you could set aside one or two developers to perform bug fixes and tackle production issues on the AngularJS app. You would inform customers that new features will be considered but will likely take some time to become available in the app. You would then concentrate the rest of your engineering effort on rewriting the app in Angular. This allows you to support your current app as it stands whilst reaching feature parity with the new Angular version of the app. UpgradeModule UpgradeModule is a tool provided by ngUpgrade by Angular to aid in the migration process. It allows you to run a hybrid application, mixing Angular and AngularJS apps. There is no emulation; it runs both frameworks at the same time. UpgradeModule provides us with two options on how we run our application. We can either run the AngularJS app and downgrade our Angular code into it, or we can run the Angular app and upgrade our AngularJS code into Angular. The Angular docs provide incredible documentation on setting up the hybrid application (you can read more here). We'll cover the basics here. Downgrading to run in AngularJS Generally, AngularJS apps can be bootstrapped using the ng-app directive such as: ` However, for ngUpgrade to take full effect you need to manually bootstrap AngularJS: ` The next step in running the latest Angular framework in the AngularJS context is to load the framework itself. This involves an outdated setup process where we need to use SystemJS to set up our Angular framework. The Angular framework no longer uses SystemJS by default for loading the framework; however, they have written a guide on how to do this here. We then set up Angular to provide it with a reference to the AngularJS App and more importantly, its Dependency Injector: $injector. ` Notice that this.upgrade.bootstrap has the same signature as angular.bootstrap. The final thing to do now is to bootstrap the Angular framework, which is done easily with one line: ` Now we can create new Angular components and downgrade them into AngularJS. Say we have an Angular component called HelloComponent. We use downgradeComponent provided by ngUpgrade to allow this component to be available to use in the AngularJS app: ` We can then use this in an AngularJS template: ` _Notice that the directive is registered in camelCase (helloWorld) but we use it in our HTML with kebab-case (hello-world)._ You're all set up to start migrating your components to Angular and downgrading them to be used in AngularJS. However, I like to think you'll agree that there is a lot of setting up here, and it leaves you with an Angular codebase that uses SystemJS to bootstrap and load your app. Upgrading to run in Angular We can take a different approach with ngUpgrade and UpgradeModule, however. We _could_ lazy load our AngularJS app into an Angular app that was scaffolded by the Angular CLI getting the full benefit of the build tools and leaving us with a codebase in line with the latest Angular. The Angular docs provide a great guide on setting up the Lazy Load Approach. It involves four things: 1. An Angular Service to lazy load AngularJS and bootstrap the AngularJS App 2. A file providing an entry point for AngularJS and the AngularJS App 3. An Angular Component to render the AngularJS app (a wrapper component) 4. Telling the Angular router when to route within the AngularJS app Once these are complete (the Angular docs really do explain this best), you can start creating new Angular components and downgrading them to be used in the AngularJS app similarly to how it was done in the previous section. You _also_ get the benefit of a more straightforward method to upgrade AngularJS services to be used within Angular: You create a factory provider and add it to the providers array of your Angular Module: ` This means you can focus on upgrading your AngularJS components first, then circling back to your services afterwards. This approach allows you to use all the modern Angular tools as well as providing you with an option of splitting up your AngularJS into smaller modules and only loading them as required. It also allows you to focus on upgrading smaller chunks of the AngularJS app at a time. Take a look at this folder structure for an example: You would store the relevant AngularJS code for the feature in the corresponding angularjs folder. This means your team can focus on one feature at a time without losing any functionality for your customers. Angular Elements Another approach that is gaining some popularity is to use Angular's Web Component solution, called Angular Elements. Angular Elements allows you to package up your Angular Component as a Web Component enabling it to be distributed and rendered in a plain old JavaScript context. This is awesome for migrating AngularJS codebases. It means we can create an Angular Component, bundle it as a Web Component and drop it into our AngularJS codebase with less set up than the ngUpgrade approach. This approach _does_ have some drawbacks. We need a good build pipeline that will bundle the Angular Components, make them available, and include them into the AngularJS codebase so that they can be loaded and used in this context. One approach to take that employs this would be to create two folders: one for your AngularJS codebase, one for your Angular codebase. You would keep your AngularJS codebase as is. All new work would occur in the Angular codebase. You can use the Angular CLI to scaffold out a monorepo. Each component you intend to upgrade would live in its own /projects folder (this is an Angular CLI workspace convention). To do this, you can run the command: ng generate application my-component Next, you need to add Angular Elements to your workspace: ng add @angular/elements --project=my-component This would create a folder and accompanying files at /projects/my-component. You would then create your component: ng generate component my-component --project=my-component This will scaffold out the component files you need. Once you have finished setting up your component, you need to use Angular Elements to convert it to a Web Component. Modify the app.module.ts at the root of /projects/my-component: ` When we build our app, we need to copy the output into a public folder in our AngularJS codebase. To build the elements file: ng build --prod --project=my-component This will produce output similar to: Notice that it created 4 files: 3 JavaScript files and one CSS file. They contain hashes to allow for cache-busting. However, it would also be worth bundling these together and naming them related to the component. We can do this with a simple node.js script (concat-elements-bundle.js): ` We can run this on the command line using node: node concat-elements-bundle.js This will output something similar to: my-component.bundle.1610106946217.js We then need to copy this to a scripts folder in our AngularJS and include it using a script tag in our index.html file: ` We can then use our component anywhere in our AngularJS app: ` This approach allows us to incrementally upgrade components to Angular, using Angular's modern tooling without changing our existing app's set up much. Once all components are upgraded, we have to place the components together in an Angular app, completing the migration. With a good CI Pipeline we _could _ automate the bundling and inclusion of the Angular Element in the AngularJS app, requiring even less work as the migration moves forward. Best Practice for Upgrading No matter the approach taken, one thing remains consistent between the two of them: how we tackle the migration. Consider our application to be a tree of components. The closer to the root of the tree, the more complex and usually more coupled the components are. As we move down the nodes in the tree, the components should get simpler and be coupled with fewer components. These components, the lowest hanging fruits, are ideal candidates for migrating to Angular first. We can migrate these components then use them in the AngularJS app where appropriate. Let's say we have an AngularJS TodoList Component which uses an AngularJS Todo Component. At this point, we can't really migrate the TodoList Component to Angular as we would have a dependency on the AngularJS Todo Component. We can migrate the Todo Component to Angular first and use it in the TodoList Component. This makes it easier to migrate the TodoList Component as its dependency on the Todo Component is already an Angular Component. We can use this approach when migrating legacy codebases. Start from the bottom and work our way up, and I would say this is the best approach. Conclusion With AngularJS losing support at the end of this year, it's worthwhile looking at migrating any legacy AngularJS codebases as soon as possible and figuring out a plan to do so. Hopefully, this article has illustrated the different options available for you to do this and helped provide an approach to tackling migrating the components in your codebase....

Jan 13, 2021

8 mins

AngularJavaScriptTypeScript

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh

In this episode of Leadership Exchange, host Rob Ocel chats with Jerry Reghunadh, Senior Director of Enterprise Architecture at Data Nimbus, about leadership, AI adoption, and data-driven decision-making. Jerry shares his career journey, insights on leveraging tools like ChatGPT and Copilot, and strategies for building effective data pipelines. They explore how companies can avoid "analysis paralysis," adopt AI strategically, and evaluate new technologies to solve real-world problems. Tune in for practical advice on aligning innovation with business goals and staying competitive in a rapidly evolving tech landscape. Chapters 00:00 – Introduction 00:31 – Jerry’s Leadership Journey 02:01 – Discussing AI in Leadership 03:59 – Experimenting with AI Tools 06:24 – Overcoming Analysis Paralysis 09:18 – Importance of Early AI Adoption 13:12 – AI’s Impact on Efficiency 14:30 – Sponsor Message 16:26 – Setting Realistic Goals for AI 19:41 – Data Management and AI 23:09 – Is AI Just a Fad? 27:22 – Testing New Technologies 29:56 – Final Thoughts on AI 30:25 – Connect with Jerry 30:44 – Closing Remarks 31:20 – Outro Follow Jerry on Social Media Linkedin: https://www.linkedin.com/in/jerrymannel/ Sponsored by This Dot: thisdot.co...

Nov 18, 2024

1 min

AIEngineering Leadership

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Problematic Try-Catches in JavaScript

Problematic Try-Catches in JavaScript

So what's the problem? 🤔

1. Which method is throwing the error?

THIS IS PROBLEMATIC

2. What if both methods should throw?

THIS IS PROBLEMATIC

3. I need to use `mutatedResult` for another action

THIS IS PROBLEMATIC

We see problems, but what's the solution? 🔥

Introducing no-try! 🚀

Colum Ferry

You might also like

Learning Paths for Next.JS Developers with Ankita Kulkarni

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

Migrating AngularJS to Angular

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh

Let's innovate together!

You might also like

Learning Paths for Next.JS Developers with Ankita Kulkarni

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

Migrating AngularJS to Angular

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh

Problematic Try-Catches in JavaScript

So what's the problem? 🤔

1. Which method is throwing the error?

THIS IS PROBLEMATIC

2. What if both methods should throw?

THIS IS PROBLEMATIC

3. I need to use mutatedResult for another action

THIS IS PROBLEMATIC

We see problems, but what's the solution? 🔥

Introducing no-try! 🚀

Colum Ferry

Learning Paths for Next.JS Developers with Ankita Kulkarni

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

Migrating AngularJS to Angular

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh

Let's innovate together!

Learning Paths for Next.JS Developers with Ankita Kulkarni

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

Migrating AngularJS to Angular

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh

3. I need to use `mutatedResult` for another action