Hah, thought this looked familiar… I had a similar idea back in 2017 and published a little 5-line library to get this type of syntax ([err, result] for async): https://github.com/timwis/eres
Safe Assignment
11–15 of 15 posts
Re: Safe Assignment
#12This may be unorthodox for JS, but I treat exceptions like panics and use error values if I care about them. This also gives me type checking in TypeScript.
Re: Safe Assignment
#13This would make certain things more convenient, but wouldn't be very versatile and would feel terrible in terms of overall language semantics
Try expressions (mentioned in other comments) seem significantly better, but still feel like they're trying to tack on something that fits awkwardly into the original language design (though that's kind of the history of JavaScript)
Anyway, I'd use those all the time if they landed
Re: Safe Assignment
#14"To access errorMsg outside of the try/catch block using const or let you have to define it outside of the block."
Just use var, then.
Re: Safe Assignment
#15The real safe assignment that I want to see is for optional chaining to be valid in LHS of assignments: foo?.bar = 42; This would not perform the assignment if an optionally chained value was nullish. It downlevels to foo == null ? undefined : foo.bar = 42; Given that the assignment is a SyntaxError now, this should be possible.
Would it evaluate the RHS? It feels like it shouldn’t, but somehow that seems weird too.