If you've scrolled through dev.to lately, you've probably seen headlines like "Say goodbye to try/catch!" promoting a new JavaScript operator: ?=, the safe assignment operator.
It's a neat idea, and worth understanding. But before you rewrite your codebase, there's an important caveat: you can't use it, and it's unlikely you ever will. Let's look at what it proposes, why people liked it, and what you can do today to get the same benefits.
Every fallible step needs its own try block. Variables have to be declared with let outside the block so they're visible afterward. The happy path gets buried.
The safe assignment operator proposal suggests a new operator, ?=, that runs the expression on the right and gives you back a tuple of [error, result]:
The rules are simple: If the call succeeds, you get [null, result]. If it throws (or the promise rejects), you get [error, null].
If you've written Go (val, err := doThing()) or used Rust's Result, this will feel familiar. Putting the error first in the tuple nudges you to check it before touching the data.
The proposal also described a Symbol.result protocol, so objects could define how they report success and failure through that tuple shape.
Here's the part many tutorials skip. The proposal started as a draft from a community member. It got a lot of attention on social media and then a lot of pushback on the ECMAScript discussion boards. Critics argued that: It isn't really about assignment. The operator acts on the expression on the right, but errors can be thrown in other places before that call even happens. ?= looks too much like existing operators, like the nullish coalescing assignment ??=, and is easy to misread. It only works in assignments and declarations, while a try-expression approach can be used anywhere an expression can.
The proposal's own repository says it will move toward try-expressions as a more idiomatic way to solve the same problem. Several commenters on dev.to posts about ?= point out that the operator was effectively abandoned. So treat any article telling you this is "coming soon" with skepticism.
The good news is that the idea doesn't need new syntax. A tiny helper gives you the same ergonomics:
There are also small libraries on npm that do the same thing, if you'd rather not maintain your own helper.
Pros Flatter, more linear code Errors are handled right next to the call that caused them No let declarations hoisted out of try blocks
Cons You can silently ignore the error if you forget the if (error) check It's not idiomatic JavaScript, so teammates may find it unfamiliar Throwing and catching still works better when you want errors to bubble up to a central handler
A good rule of thumb: use the tuple style for local, expected failures (a network call you want to retry, parsing user input), and keep try/catch for unexpected failures that should propagate.
The safe assignment operator is a good case study in how JavaScript evolves. A catchy idea spreads fast, the community debates it, and the final shape often differs from the first sketch. ?= itself probably won't ship, but the underlying question of how to make error handling less verbose is very much alive, and try-expressions are where that conversation seems to be heading.
What do you think: would you use errors-as-values in your JavaScript, or do you prefer good old try/catch? Let me know in the comments.