DEV Community

Stop Using Try-Catch: A Better Way to Handle Errors in JavaScript

Richard Shaju on November 03, 2024

JavaScript developers, there’s a new way to handle errors without relying on messy, repetitive try-catch blocks. Meet the Safe Assignment Operator ...

Read full post

Jon Randy 🎖️ • Nov 3

This operator is a very long way from becoming part of the language, if it ever does. It's from a DRAFT proposal that hasn't even been accepted for consideration yet, let alone inclusion.

Chris Walsh • Nov 4

Articles like this always seem to gloss over this point which is really annoying.

Chani Diakidis • Nov 4

I just wish that people stop using stop doing/using [placeholder].

Duy K. Bui • Nov 4

Totally agreed. Just because there is a new alternative that is applicable in some use cases doesn't mean everyone should abandon the status quo.

Oziel Perez • Nov 4

That's modern React in a nutshell

Kirill Birger • Nov 5

Modern react is an oxymoron. React is a framework that is permanently stuck in some sort of dystopian alternate history universe

Adrian Zochowski • Nov 5

Calling React a framework is like comparing a cat to a mouse. If you can't figure out that much, why even try to make any other comparison's.

Jeysson Guevara • Nov 4

From the creators of "you're doing [placeholder] wrong" and "[placeholder-1] will change [placeholder-2] forever", Clickbaity studios! 🤣

Nathan Collins • Nov 4 • Edited

It's one of the reasons I deleted my Medium account and now it's permiating here too.

Stop telling us what totally normal and absolutely fine thing is bad.

Peter Koves • Nov 4

Maximally agree. I search for "Stop Using on this site, and got 50+ hits.

Josiah Bryan • Nov 4

Why? You mean like for the returning another error or something? Not sure why that's a problem, honest question, just curious what you're thinking?

The Returning Soul • Nov 4

No, OP commenter meant to not use such phrase for clickbait article title

Dinma Zilla • Nov 3

The second example is somewhat confusing to read. The Try/Catch syntax is very intuitive. 👍🏼

Magic Weaver • Nov 3 • Edited

great article! for anyone wanting to try a similar approach to the ?= operator now, i created safe-wrapper to handle errors gracefully. inspired by the safe assignment operator proposal, safe-wrapper returns a tuple [error, result] for both synchronous and asynchronous functions, reducing try-catch blocks.

it also includes type-specific error catching, allowing you to specify which error types to handle, throwing any unexpected types, for precise error management.

check out the npm package and give it a try!

Richard Shaju • Nov 4

Thanks for sharing

José Pablo Ramírez Vargas • Nov 4

Clearly the efforts made towards "centralizing" the error handling code makes it more complex and less intuitive than the try..catch version. While I see some value in this potential new operator, I don't think it is such a game changer.

Sti Selini • Nov 4 • Edited

I do not, and never will, use nested try catch within a function. I almost never use it serially unless there is a massive reason such as immediate recoverability from the error, or state rollback, or a darn good logical reason, which is almost never.

I can count on two hands the number of patterns I've violated this rule with in JavaScript, Java, C++ and other languages in the last 35 years.

The reason you need solutions like this is you're writing bad code to begin with and have poor error handling design.

Cody Swartz • Nov 4

You could give a library like TS Results or Never Throw a try which gives additional tooling and abstractions that provides some quality of life & niceties, which can be used right now.

Given that this is not currently implemented for LTS I would recommend an abstraction like a library which could later utilize this method under the hood if/when it makes sense.

leob • Nov 4

What? This looks identical to a post that I saw on dev.to a few months ago - why and how is this being "recycled"? Besides, this isn't even an accepted proposal, let alone it's implemented in JS already, so it's misleading to say "stop doing this or that" when the alternative doesn't even work ...

Besides, people should stop writing article titles like "STOP using this ..." or "you MUST do that ..." - we're not toddlers, we can make our own decisions and trade-offs, rather than being patronized or being told what we "must" do (even more so when the actual information is inaccurate or misleading) ...

How and why did this article make it to the top of my "dev.to" feed? Pretty useless ...

Sergei Kostov • Nov 4 • Edited

I made an account just to write this!

How can I down vote this. What an awful idea! This is going backwards. This is de-evolution. Degradation. Only people who have never in their life had to program in a language who has no exceptions may propose things like this.
Stop it get some help!

Rene Kootstra • Nov 4

My take on this is that most code has to many try catches anyway. The example above could have been just one try catch
The file successfully loaded or not. The reason why it failed, a file load failure or parsing becomes clear from the error stack trace.

On the safe assignment operator itself. I kind a like it but not convinced it is a game changer

Marc • Nov 4

How is this better? Proper use of try catch results in clean code because you have zero error handling in your main code - it’s all at the bottom making the happy flow easier to read. Your example is just bad try catch usage and one can easily imagine bad usage of the new operator where you end up with an if after every command - the whole reason exceptions were invented.

emwadde • Nov 4

Here is a better article to read about
[the same concept](dev.to/polakshahar/stopping-errors...

Lars Rye Jeppesen • Nov 4

I am unsure how this makes the code simpler .
Often you want to propagate thrown errors to previous layers of code, ending up with a top level error handler

It seems this approach will require you to deal with the error where it happens, which will lead to MORE lines of code, and spreading of the error handling logic.

What am I missing?

Jesse Ditson • Nov 4

FWIW, language features like this are super fun, but as Jon Randy points out, not in the spec - and in this case, it is very unlikely to ever be accepted, as try expressions looks more likely to be the solution to block-based try/catch. I'm sure you'd get less push back if you changed the title of this article to something less clickbait-y like "exploring the ?= operator in javascript" or "how to use experimental safe assignment in javascript".

For those interested in more context, here's the proposal (note the author's warning at the top):
github.com/arthurfiorette/proposal...

Here's the larger discussion: github.com/arthurfiorette/proposal...

FWIW the proposal that (at the time of writing) looks most likely to make it into the language is actually a new try operator that works during assignment:

const [err, data] = try await mayFail();

It's somewhat similar to your article above, so perhaps a note that we're likely to get this functionality in typescript and later ECMAScript somewhat soon, but that the operator itself is still being discussed. And of course, if you have strong opinions, join the discussion and voting on the proposal thread!

Patrizio Bruno • Nov 4 • Edited

You could have written the try-catch example in 5/6 lines of code, but decided to overcomplicate it just to make your case. Well done, I took the bait, this time 🙂 Another article like this and I delete my subscription.

Scott Molinari • Nov 5

To everyone reading this, it is a proposal and the "?=" operator more than likely won't be used, because it too close to nullish coalescing assignment. The more agreed upon solution (currently) is something like:

const [error, data] = try mightFail();
const [error, data] = try await mightFail();

See the draft: github.com/arthurfiorette/proposal...

Scott

Gene Xu • Nov 5

I don't think this will be a game-changer. It looks similar to Golang syntax but without a defer function, the one of important parts of error handling in the Golang world.

Golang example:

func some() (thing) {
    src, err := os.Open(srcName)
    if err != nil {
        return
    }
    defer src.Close()
}

Actually, if you are using typescript, you can do something like this:

async function fetchData() {
    try {
        await yup.string().eamil.verifySomeValues();
        const data = await axios('fetch some data');
        // do something for data...
    } catch(err: unknow) {
        if (err instanceof AxiosError) {
            // handle axios errors
        }
        if (err instanceof yup.ValidationError) {
            // handle yup validation error
        }
        const e = err as Error
        // handle other exception errors
    }
}

It's used in my recent project and is more readable for me.

Tako Schotanus • Nov 4 • Edited

Those two pieces of code are not equivalent, in the first you are distinguishing between the two different errors while in the second you aren't (and can't anymore, you've lost that information).

If you don't care about detecting different errors but just any error then the first example becomes just as simple as the second one.

In fact if you have more complex code with multiple places that can generate errors than the try-catch becomes simpler again because you could have a single try-catch block instead of needing if-statements for each.

So the operator might be nice in some circumstances (especially in JavaScript where most errors are untyped) but I don't see any real advantage, only a stylistic choice.

Mitch Chimwemwe Chanza • Nov 4 • Edited

I thought the reason is dangerous , if it's about readability haa check how spaghettish Java is 😆😆😆

Don't get me wrong am not criticizing your article. Infact I love it. Am just justifying how this operator could not be ideal

My opinion 🤣🤣

Greg Silverman • Nov 4

If each type of error is handled the same way, by logging for example, this operator makes the code cleaner. But if there are different recovery responses for different errors you would need if-then or if-then-else or switch statements, so, not cleaner.

Sergey Latkin • Nov 4

Is it a clickbait repost, or what?

It looks like a newly re-generated version of this post: dev.to/paharihacker/effortless-err...

Maciej Wakuła • Nov 4

readFile(...)
.then(data=>cfg=JSON.parse(data))
.then(runCode(cfg))
.catch(alert("an error") ;

You can use Promise syntax (but that is causing some other problems).
You can use try-catch (preferably dividing your code into smaller pieces).
You could use whatever unofficial extension that you create a polyfill for. Like "?=" which is not yet supported.

JavaScript has the flexibility of not using types (though you could use typescript, jsdoc and even check types during runtime). It offers multiple ways to solve different types of challenges - you just need to pick the best for your case and know what are the consequences (you sacrifice something to gain other thing).

I would not tell "don't ever use this feature". However I could list pros and cons of some features. I encourage you to look wider and check whether there are niche scenarios that could fit other options (or maybe your case is the niche?).

Peter Koves • Nov 4

What a strikingly modern approach!

I remember this kind of advice from the start of my IT career in the 1970-s.
"There is a return code from every system call. Be sure to check it after each call and take appropriate action if an error is indicated."
Mind you, when code was presented in articles like this, the error handling was omitted for clarity.

Al Amrikasir • Nov 4

Creative approach, if using try-catch statement just for one-line code like "just" fetching URL or open file etc etc, its a good way.

Try-Catch still used to handle many statements, fetching URL, parsing JSON, save or update to DB, or forward response to another URL.

Just like ternary operator, bool ? If-true : if-false, it's good to handle one-line statement.

Anyway, this is good thread, new way to handle things is one of the best part of programming 🍻🍻🍻

No • Nov 4 • Edited

It's a bad example in the first place because you're just recreating built-in error handling, but if you really needed something like that:

const fileContents = await readFile('config.json')
  .catch(err => console.error('Error reading file:', err));
const config = fileContents && await Promise.try(() => JSON.parse(fileContents))
  .catch(err => console.error('Error parsing file:', err))

config && console.log('Configuration loaded successfully:', config);

Promise.try isn't supported in Safari but you can either polyfill it, or use new Promise(r => r(JSON.parse(...)))

Kirill Birger • Nov 5

This is impractical beyond belief.

You are now writing extra code for conditions which should never occur.

If there's a readError, you should not ever get to the code that would generate a parseError. That's what try catch achieves. It may feel unwieldy, because of the nesting, but in this example it is more effective and manageable.

You could simply use try-catch to provide the same pattern of returning an error object instead of a result from the function that reads a file.

See: fantasyland, result pattern, either pattern
Seealso: fp-ts, purify-js

click2install • Nov 5

If developers would stop using errors for control flow you wouldn't need this crap scattered throughout your code in the first place. Maybe next time, at least wait until it's supported in Typescript - then it'll be widely accepted as a standard as it will be past Stage 3.

Yonatan Galili • Nov 4

Stop using clickbait to waste my time.

Please avoid using clickbait that wastes readers' time. Clearly state at the beginning of the article if it is a proposal, so readers don’t have to sift through comments to discover this only after investing time. While well meant, with limited time and attention, articles like these can be really frustrating.

Padmanabhan S • Nov 4

I can't get it together please help help me here , so based on this article , the async functions returns array now for destructuring ?, If it is why the '?' before '=', I think this '?=' Is bit far, cause even we use '?=' We have to wrap the logic under an if condition like they explained above in the example . Normally '? ' represent ' likely if ' for eg Ternary operator .
I know I am not that much of developer , so please hammer some reason behind his into me thanks in advance.

Iam sorry if I used harsh words, cause Iam new to comment, I'm still learning.🙏

warmfeet • Nov 4 • Edited

This is what happens when the third world starts trying to code.
Can't tell you how many times we've had to throw away code that some third worlder visa recipient contracted from his home country of third worlders, millions of dollars wasted, for Americans to clean up the mess.

Get out of here with this junk

Riccardo Basile • Nov 4

Another article in which the autor ditches on a topic in favor of a "NEW STILL NOT SUBMITTED PROPOSAL", claiming that is the new game changer.

PLEASE - stop producing this kind of garbage - people end trusting you.

OR - write it as it is: "there is a guy with an idea, this is the github project pahe with his proposal still in draft that..." and you explain what you are referring to and your excitation for the topic.

BUT passing the thing as if it was already in the JS spec is a clickbaitish strategy
OR it could be a strategy to spread the topic and get more people pushing for its proposal - idk

TO ME: I'm reporting this article as scam.

Danielle Brear • Nov 4

This is neat but readability is lost. The try/catch flow is vertically longer but it’s so much easier to follow. Expecting people to know that this operator somehow makes js into golang is going to confuse more people than it impresses.

Guy Nicholas • Nov 4

I'm sorry, but the example is lame. The nested try/catch handles a pair of errors differently, where the ?= example handles them as one. The original try/catch could have done exactly that by removing the inner try/catch.
Depending on the situation, I will sometimes nest the try/catch just to adjust the thrown error or to do some logging, and then re-throw. In my case I am writing server code and one error may be a 400 while another is a 500

Eugene • Nov 4

It resembles Golang way but written quite awkwardly. Typically it should handle potential errors returned and terminate execution if any, then, proceed further.

David Guthrie • Nov 4

This is wrapping exceptions into old style return code errors. It's reliving all the mistakes of the 80s. The resulting code looks just like return codes, and then uses a contrived example of bad exception handling to make exceptions look worse. They each have their tradeoffs, but return codes nearly always result in more code.

Matthew S • Nov 4

I wonder if there will be a performance penalty for using this like try catch has. If there isn't I would definitely be using the syntax. But I'm pretty sure like all new language features the engines have difficulties optimizing it over older and more well-known syntax. Ultimately I think this is just going to be syntactic sugar with the same caveats the old way of doing it.

Hari B • Nov 5

try ...catch ... finally is a proven statement. Messiness is just a relative term. From my experience, I am sure this operator can be a complement but not a replacement, at least for now.

I personally don't have any interest to replace try catch with it, but glad to see other perspectives.

Nice article!

Patrick • Nov 4

Your writing is always engaging! I'd also like to recommend EchoAPI for JavaScript projects. It has truly enhanced my development experience, providing powerful tools for efficient API management.

Munene Ndereba • Nov 5

Inspired by go?

Adrian Zochowski • Nov 5

I'm not sure where you got the examples but your if else is worst than the try catch itself. I suggest you learn basics first.

Haakon Hestness • Nov 4

Stop with the clickbait already. So annoying to see things that you can’t implement 💩🤬

Taufik Nurrohman • Nov 5

Actually, you could remove the nesting try/catch block and wrap the whole code with one try/catch block.

tomas-dirac • Nov 4 • Edited

Is it deopt in v8? Try catch where optimized not that long before and its flaweless interesting how this behaves in performance critical code.

Jeremy Smith • Nov 4

Not for me, sorry.

Robert Sizarov • Nov 4

No, it’s not easier to read. It’s just a different way to note down the same thing. I don’t think the second example solves any problem.

KristijanFištrek • Nov 4

Yeah, let's replace the simple try - catch with another hook logic. Perfect. Just what I needed.

Itay Yaffe • Nov 4

Which browsers support this operator?

DerMorzi • Nov 4

Have you read the proposal? This syntax is deprecated, and the proposal is far away from be implemented in the runtimes. So this article has no value.

HB_the_Pencil • Nov 4

This is neat! I haven't done much with try-catch in JS (I'm moving more towards Python), but this is cool. Is there a more efficient way to do this without having to define tons of variables?

Glen Little • Nov 4

Would be nice, but it doesn't exist today.

WORMSS • Nov 4

Are we just gonna ignore that you didn't await the fetch before requesting the json body?

Jason Zamora • Nov 4

It's like someone saying "You've been using the can opener the wrong way!" ..."Stop that, do this."

cosma203 • Nov 4

I have a strong feeling this article is purely AI generated. Maybe i'm wrong. And if there is one term that screams AI to me, it's got to be game-changer. I'm honestly sick of that term. :D

Jafar • Nov 4

I like it, ignore the doubters. Try/Catch is sloppy.

whyte50 • Nov 4

I really don't see the point of this new syntax. It just puts all your code in one line, I don't believe it's as neat as try/catch and I can see it becoming very messy in the long run.

oskar • Nov 4

it's better to use libs such as await-to-js imho

Lars Rye Jeppesen • Nov 4

Or learn to write cleaner code, without nested try catches.

Cezary Mikołajczyk • Nov 4 • Edited

I think it's best for singular functions. It's hard to read big codebase with something like that. Really, depends on your app. Always keep the niche in mind.

Bum-Ho12 • Nov 4

It simplifies the structure but increases difficulty in readability

Niall Moran • Nov 4

Feels a little like on error resume next in the very old days of VB. If I don't check the error variable my code keeps running? Source of a lot of dangerous bugs.