khaosdoctor
commented
2 weeks ago Valid arguments, a good write up, but I disagree on a few things.
- Simplified error handling is indeed a matter of opinion, one which we don't have anywhere to run because the only way to handle errors in JS is with try or
.catch.
The nested code will probably not be written like this, just look at how they do it in Go... I'd do it like this:
async function getData() {
const [fetchError, response] ?= await fetch("https://api.example.com/data");
if (fetchError) return console.log(`Error getting data: ${fetchError}`);
const [jsonError, json] ?= await response.json();
if (jsonError) return console.log(`Error getting data: ${jsonError}`);
const [parseError, parsed] ?= validationSchema.parse(json);
if (parseError) return console.log(`Error getting data: ${parseError}`);
return parsed
}else is (most of the time) an useless construct of any language.
Now this:
async function getData() {
return await fetch("https://api.example.com/data")
?& async response => await response.json()
?& json => validationSchema.parse(json)
?| error => (console.log(`Error getting data: ${jsonError}`), null);
}Is elegant, I'd love to have it as pattern matching in JS, but it is unreadable.
Consistency Across APIs
JavaScript is not, was not, and will probably never be consistent. I talked about this on #24:
setTimeoutuses callbacks, along with all the timersXHRHttpRequestis event-based, whereasfetchis promise-based- All JS events are (you guessed), event-based
- Async iterators do not return a callback, which should be the consistent return, right? Since
setTimeoutis there since before them. But they return promises - You can handle errors in promises with
.thenas well as with.catchthe difference is the second parameter of then, when null, is ignored - Async/await is the exact same thing as
.then/catch, the only difference is the nesting level, which is exactly the same proposal as this one - You probably saw all the JS memes about how inconsistent it is I guess...
My point is, there's no point on trying to unify and make the library consistent now, 29 years later, when we can't deprecate any old function. If that was the case, parseInt would've been out for ages and jQuery would've been forgotten.
Do you know what is enforceable? Just returning an error-value tuple outright. And that doesn't require any new magical syntax, either. Of course, all other arguments above still stand for returning a tuple.
But that would require a MASSIVE change to all the previous APIs that you just said cannot be broken. I'd love that JS had Go-like (or even Python's) multiple returns with enforced error handling, but it can't, it simply is not possible not because of the technical side, but because of the operational side.
alray2569
DScheglov
figloalds
JamesRamm
ljharb
I won't beat around the bush: I don't like this proposal. I don't think it achieves any of its stated goals. Let's go through them:
Simplified Error Handling
This is the weakest motivation listed because it provides no explanation of why try-catch blocks are more complicated than "safe assignment," or what exactly safe assignment is supposed to simplify. As far as I'm concerned, this is purely a matter of opinion.
Enhanced Readability
Compare the following code: snippets
In the first one, all of our application logic is grouped together into the try block, and the error handling is grouped together into the catch block. In the second example, the error handling code interrupts the application logic. By splitting apart logical contexts, we have made the code less readable.
Especially ironic is the claim that safe assignment will reduce nesting. Consider your example code:
The most logical error handling in this case is to log the error and return null. And despite much hand-wringing about different types of errors, we don't actually care what error happened because either we got our data or we didn't. So let us fix this code with try-catch:
Let us now fix the same code with safe assignment (and without the heavyhanded multiple returns in the example solution, since they are both inconsistent with the function contract and introduce flow complexity):
This could hypothetically be mitigated by some sort of safe-coalescing operator, say,
?&. (For people who are interested the gritty theoretical details, this would turn the safe assignment pattern into a monad withunit = value => [null, value]andbind = (a, b) => a ?& b.) In practice, this would look like this:If we also added a safe-fallback operator, say,
?|, we could specify a default value inline, for example:Now we're actually getting into the realm of being more readable than try-catch. (By the way, if this code looks strangely familiar, that's because it's basically the same thing as
.then/.catchfor promises, but with a uniform operator instead of a bespoke set of methods.BUT —
?&and?|pretty much obviate?=. We can use the former pair to chain and handle errors before we even make an assignment. So this is really starting to look like an alternative proposal now. You'll notice that?=is gone from my example.Consistency Across APIs
Ah, yes, a classic: Let us achieve consistency across APIs by giving API developers yet another way to be inconsistent. Need I say more?
Improved Security
This only improves security if we break every existing API to enforce the use of safe assignment. As long as I can forget to use safe assignment, it's not safe. And of course, if we rewrite things like async/await and parsing to enforce safe assignment, we break decades of code. Certainly, this could be enforced by a linter, but so could try-catch.
Do you know what is enforceable? Just returning an error-value tuple outright. And that doesn't require any new magical syntax, either. Of course, all other arguments above still stand for returning a tuple.