Let's Clean Up: Ugly Try-Catches!

We've all been there. We have all usedawait onasync methods, forgetting to wrap them intry-catch just to be told off about anUnhandled Error 😱

But it's not just theseaysnc methods that might throw. Perhaps we use a third-party library that throws, or we design our codebase in such a way that we throw errors intentionally to bubble error handling up a few layers.

So we proceed by wrapping our calls to the throwable methods in ourtry-catch blocks.

Perfect! 😍

🤔 Or is it?

Working in a code base where you can expect methods tothrow can lead to situations where your logic is wrapped intry-catch blocks. It also leads to other code design problems.

Take a look at the examples below:

try{constmyVar=myThrowableMethod();}catch(err){console.log(err);}// Wait, there's an error here:console.log(myVar);// myVar doesn't exist outside of the try scope.

As we can see above, themyVar variable doesn't exist outside of thetry block. But we need that value to continue our logic!!

So now we need to do something a little different.
How about:

try{constmyVar=myThrowableMethod();constnewVar=manipulateMyVar(myVar);constresponse=sendApiRequest(newVar);returnrespponse;}catch(err){console.log(err);}

🤮!

No. Let's not do this.

Now all our logic wrapped inside thetry block. That's ugly.
Also, if any of the subsequent method calls throw, are we sure we want to handle them the same way!? Possibly, but most likely not!

Ok, let's try something else...

letmyVar;try{myVar=myThrowableMethod();returnrespponse;}catch(err){console.log(err);}constnewVar=manipulateMyVar(myVar);constresponse=sendApiRequest(newVar);

This is a little better, but still not perfect. It's still ugly asmyVar has to be declared then initialised almost immediately after just in a different scope. It also presents an issue whenmyThrowableMethod does throw, as execution will continue and try to usemyVar!

🐛 Alert!

I could keep going, giving more situations where thesetry-catch blocks can present code design, readability, and maintainability problems.

Instead, I'll present you with a solution!

The Solution 🚀

I wrote a small library to tackle this issue head on :

Let's welcomeno-try to the scene. 🎉

What isno-try? 😱

no-try is a tiny library that takes thetry-catch out of your code, improves the readability and maintainability of your code whilst helping to improve code design.

It exposes two functions.noTry andnoTryAsync with the latter resolving and returning the result of Promises.

Don't believe me? Let's look at it in more detail.

To install it, simply runnpm i --save no-try

Then add it to your file:

In TypeScript;

import{noTry}from"no-try";

In JS:

constnoTry=require("no-try").noTry;

Now, let's refactor our example above to useno-try.

const{result,error}=noTry(()=>myThrowableMethod());if(error){// Handle errorreturn;}constnewVar=manipulateMyVar(result);constresponse=sendApiRequest(newVar);

🎉🎉🎉

Isn't that cleaner!?

If you have a standard error handling function, you can supply that tonoTry and it will invoke it for you if an error occurs!

functionmyCustomErrHandler(error){// Do something to handle error}const{result,error}=noTry(()=>myThrowableMethod(),myCustomErrHandler);if(error){return;}constnewVar=manipulateMyVar(result);constresponse=sendApiRequest(newVar);

And that's it!

We've removed thetry-catch blocks from our code, preventing issues relating to block-scoped variables, whilst also allowing our code to be much more readable without sacrificing the flexibility of handling the error how we want.

You can read more onno-try over onGitHub.

Now go clean your code!

If you have any questions, feel free to ask below or reach out to me on Twitter:@FerryColum.