If you want to shape the future of this proposal you can join an upcoming conversation Aug 25 on a google meet meeting with the author github.com/arthurfiorette/proposal-safe-assignment-operator/issues/28
Although this is an improvement over try/catch and I appreciate the Go-ness of this pattern, I still prefer pattern matching on Result in Rust with the Ok and Err methods far more. If we could get pattern matching into JS (still in stage 1), I'd be so stoked to have a Result-like convention instead of Symbol.result. Regardless, this is better than what we've got.
All of these things can be implemented with current JS. Write a factory/decorator function that returns a proxy with an Apply handler that uses try/catch and then returns an error or a result (based on the try/catch), then do a switch based on instanceof the resulting object. Then decorate any function you want to make it return an optional result. JS is super flexible without having to add new features, and we should be using the existing ones over adding new ones to make it like other languages.
Here are my thoughts: - This is obviously inspired by Go. - We use try/catch because we don't know if a function can throw an error or not. This proposal doesn't solve that problem. It kinda just adds an easier way to use try/catch but for individual functions. So instead of try {a(); b(); c()} catch (error) {...}, we will have let [errA, resA] ?= a(); [errB, resB] ?= b(); [errC, resC] ?= c();, which is equivalent to try {a()} catch (errA) {}; try {b()} catch (errB) {};try {c()} catch (errC) {}. - Without knowing if a function can throw or not, you would have to use this new operator for pretty much every function call unless you absolutely know that the function can not throw. It's still a step in the right direction though.
@@Cypekeh That's a cleaner way to write it for sure, but it is exactly the same as doing try/catch in the first way I wrote it. It's just syntactic sugar and it doesn't solve the underlying problem.
@@bricecarpentier5817 Lol you know I was thinking the exact same thing as I was writing my comment. The underyling problems of Javascript can't be solved anymore so they are just focusing on how to get developers to write prettier code.
Go's error handling is very nice actually. You know that something returns an error and you know how it should be handled and you don't have to worry about it taking down your system.
Also LOTS of people don't handle errors at all, then you have to deal with it either as a user, or as a developer who's thrown into that project to fix it :D
There's another proposal that comes into play with this. If you don't want to accept a value you will be able to use the keyword 'void' instead, like this: const [void, result] ?= await fetch(...) (why? Readability. And the current solution of just skipping bindings causes some real issues in combination with trailing commas. Like does "const [,,] = arr" try to get two or three values? Could be both.) (edit: I forgot the question mark 🤣)
This is SO good. I never understood the concept of try/catch anyway. Like, errors/exceptions are thrown on a expression or statement level. Then why is handling these done on a BLOCK level instead? That's a completely different context. That never made sense to me.
It's still a draft. In the meantime you can do this: ```javascript const attempt = (operation) => { let result = null; let error = null; try { result = operation(); } catch(err) { error = err; } return [error, result]; }; const attemptAsync = async (operation) => { let result = null; let error = null; try { result = await operation(); } catch(err) { error = err; } return [error, result]; }; ```
@@vsDizzy Marking a function as async when it doesn't perform any asynchronous operations is considered bad practice because it can lead to unnecessary confusion for those reading the code and propagate the need to handle these functions with async/await, adding unnecessary complexity.
According to the proposal the error go first, because a programmer can forget about the error, if it'll be the second element of the cortege? Here is the qoute: "If someone is using ?= as their assignment operator, it is because they want to ensure that they handle errors and avoid forgetting them. Placing the data first would contradict this principle, as it prioritizes the result over error handling." If I already use the operator "?=", I already know their might be an error. Why would I forget about it? Another qoute: "In Go, the convention is to place the data variable first, and you might wonder why we don't follow the same approach in JavaScript." I suspect most other languages would go for similar approach - data go first. Why JS should be an different? It only adds confusion, especially for those devs who use several languages in on project and constantly switch between them. Let's also not forget about multiple JS libs that use data first approach as well.
@@teamadostamine9657you wouldn't even need a special lint rule for this The typescript linter would complain if you used the unknown error value instead of the typed data value in the wrong places
There's already precedent in the Either monad that places the error in the Left. But other than that, I think in JS you'd be able to write "var [result] ?= blah();" and forget about the error if the result is first, while "var [_, result] ?= blah();" makes you explicitly discard the error value. Pedantic: both the error and the result are data, so it actually doesn't break the paradigm 🙂
This sorta thing is cool, but it also makes me kinda sad because we can already do exactly what this does without this operator, and just a few lines of JS. I see other comments saying "we should have a Rust style Ok/Err Result syntax added too". This just makes me feel like people don't write JS anymore - Both can be achieved quite easily: // Implementation class Ok { constructor(data) { this.result = data } } class Err { constructor(data) { this.error = data } } function makeOptional(func) { if (typeof func !== 'function') throw Error("Can't make a non-function object optional"); return new Proxy(func, { async apply(target, thisArg, args) { try { const ok = new Ok(await func.apply(thisArg, args)); return ok; } catch (error) { return new Err(error); } } }); } // End Implementation // Demonstration const optionalFetch = makeOptional(fetch); // ?= Style error handling const { error, result } = await optionalFetch("/index.html"); if(error) { console.error('Error fetching index.html', error) } else { console.debug('Fetched index.html', result); } // Rust Result style handling const Result = await optionalFetch("/index.html"); switch(result.constructor.name) { case 'Ok': console.debug('Fetched index.html', Result); break; case 'Err': default: console.error('Error fetching index.html'); } // End Demonstration
I don't think there's anything wrong with try-catch or using Promise.catch. I have mixed feelings about this operator. I'm not sure I'll be motivated to use it. How do you determine there's an error? Are you going to use if(error)? With try-catch, you have different blocks dedicated to normal flow and error handling. This blurs that line. Readability might be an issue
Before that we would need a "Symbol.doesError" added to all functions in JavaScript that can throw an error s.t. we can actually detect which ones need error handling.
In the proposal examples, they should really be setting the cause in the constructors of their new errors. People often forget to do that, it hides the original error
It's like error handling in go, but there error is the second argument. I think it's completely useless for js, since nobody is using fetch in place, usually it's a class or function wrapper for http calls, or axios. One more thing: almost everybody loves to catch and throw in js, so this one will be a dead feature anyway, it can make sense if js will ban try/catch which will never happen.
This is a very bad idea. Exceptions are one of the worst parts of js, you can throw literally any value and the language has no mechanism of only catching a specific kind of error. It seems like the idea behind this proposal is just syntax sugar for a Result mechanism, but basing it on exceptions means you can't know what the type of the error actually is. It also encourages you to write more code that throws exceptions so you can use the pretty new syntax, which is just making the problem worse.
I curious why not returning objects like const {error, result} ?=... With deconstruction, you can pick the parameters you need and don't stick to the parameters order, which is always a source of dummy errors. And I'm kind-of sceptical on "the main point" which is force to handle errors. Why should I? In most cases, I'm primarily concerned with "do I have required data or not?" and branch my logic accordingly. Error message are good for debutting\logging purposes, and yeah, it's better to have them, but why force? Easily accessible error message without the mess of try-catch will bump the error handling to the moon already. Other outcomes about code organisation, variable scope are much valuable
I like this approach better than using try-catch blocks, but it's just another way of writing JavaScript. I mean that since we have to maintain compatibility with previous versions of JavaScript, there are different ways of programming to solve the same problem. And we have to learn to read and write in the ways we like and the ones we don't in order to be able to contribute our solution to different projects. But it's the JavaScript way.
This wouldn't replace try/catch even if we did not care about backwards compatibility. It is not equal to a try/catch block, since a try/catch block can contain multiple lines of code, aka multiple statements. To imitate such behaviour with this operator you'd have to make an immediately invoked function that has the multiple statements. e.g. const [error, data] ?= (()=>{ // statement 1 // statement 2 })();
is like Golang of await-to-js/ts (older libs async await wrapper for easy error handling)
2 หลายเดือนก่อน
Thank you for the video, 👍 So little bit confused as low level js developer , Can Someone guide me what is proper way of using try and catch beside simple usage and how to handle the exceptions ?
Actually, it seems that using ?= leads to implicit error ignoring. There is an issue with catching falsy or nulish exceptions And finally, the Polifill doesn't polifills. Syntax couldn't be polifiled ,and Symbol.result is excessively used in this proposal. I think this proposal doesn't have chances to be ever approved
I always create a little helper/wrapper function -- which I put in an object so I can call it `safe.ly()` 😁 -- that does exactly this for any promises. It would certainly be nice to have it build into the language. (To be clear on my version: it lets you do something like `const [response, error] = await safe.ly(somePromise(...))` . And is TypeScript safe. It's *so* nice not having to chain `.then.catch` and also not having to `try...catch...` around every promise. But I also specifically like having the error be second, to be able to ignore errors/rejections if desired -- for future handler implementation later -- without them bubbling up, simply by declaring a one-element destructuring. I understand why they want to do it the other way around, though.)
Does any one know what are the possibilities of this becoming a real feature of JavaScript? I simply loved it!! Even if there is a chance of it becoming a feature of the language, i assume it would take several years, right? 😢
I simply dont understand the main reason they invented it, I think new feature should simplify code, and by that I mean make it shorter, so if my try&catch function has 10 rows the new operator ?= has to do it in 5 rows or still UNDER 10. But this looks pretty much the same length.
Biggest advantage I see is when coupled with typescript. In typescript you can just ignore thrown errors but with this you have to either handle the error or explicitly pass it up in the call chain.
try/catch in javascript is ugly, because you have scope in try block, and whatever you declare here, you can't access after. So, this potentially can remove annoying try/catch in a codebase entirely, without needing wrappers around native fetch, for example.
At least we should know if it throws, oftentimes you want an error to bubble up to the top of the request handler and just log and/or return an error response.
@@nivethan-me Well, first of all, Java is built in such a way that if a function has a chance to throw, it must be declared as such - this happens with the built in language primitives too. So, the developer knows if something throws. This leads to funny chains of try-catches which is fun to think about and a living hell to work with. But on the other hand, things do not go haywire and the applications do not crash in an unexpected way. Most of the time.
Go always kept two cups on the bedside table. One cup had water, while the other was always empty. Rust was very puzzled and asked, "Why do you keep two cups here all the time?" Go replied, "Because I need to drink water when I wake up at night." Rust then asked, "But why do you need an empty cup?" Go responded, "What if one day I wake up and don't feel like drinking water?"
I wish this would get into Java, and by Java, I mean Java 8 or 11, because no one uses later versions. Exceptions are the bane of what little terseness the language has.
This is an awful proposal. The nice thing about try catch is that it makes it explicit that you are handeling errors. this proposed operator just makes the error handling less explicit.
I think this idea is stolen from golang, because in golang functions can return two values data and error the same idea but with a tuple , yeah kts great so you can handle errors in local not in global no need for one try catch but you will have opportunity for more try catches for more flexibility in error handling
This looks similar to the one in go but this kind of pattern exist since forever. In C there's error codes. In most functional programming languages like Haskell, Scala, instead of try catch they use a monadic approach which is using Either, in Rust there's something similar also called Result. Personally I think this is a superior way of handing errors instead of try catch especially using monad/functor but that's a topic for another day
This is JavaScript, how is it enforcing the handling of the error? Because, unlike Go, you can assign variables and not use them. This doesn’t make any improvements to the language, it just means more syntax and another way to do the same thing as before. JavaScript needs to have a new mode that would force variable usage. Additionally, it would be nice for all languages to have some kind of syntax to indicate that an error could be returned from a function, this would provide information immediately when calling the function. I like the idea of function names ending with a symbol, like “?”, where a function named “fetch?” would be expected to have errors in certain cases.
I think this proposal is awful. It is not clear enough from a glance what ?= does, and when I first saw it, replacing try-catch was my last expectation. Also, changing the output, just because you changed the assignment operator, is going to cause a lot of confusion and is very human error-prone, especially when converting an existing codebase to use this.
![[Sub Thai] APT. - ROSÉ & Bruno Mars](http://i.ytimg.com/vi/bYjhzP8x_uc/mqdefault.jpg)
If you want to shape the future of this proposal you can join an upcoming conversation Aug 25 on a google meet meeting with the author github.com/arthurfiorette/proposal-safe-assignment-operator/issues/28
This can already be done without a new operator with vanilla JS.
I liked treating errors as values as soon as I encountered it in Golang.
Amen
Still better then try catch
In js they try to do like in golang, and golang is already thinking about a new alternative like in zig
wassup akhi. hry?
WP sucks btw
zig has op error handling
Although this is an improvement over try/catch and I appreciate the Go-ness of this pattern, I still prefer pattern matching on Result in Rust with the Ok and Err methods far more. If we could get pattern matching into JS (still in stage 1), I'd be so stoked to have a Result-like convention instead of Symbol.result. Regardless, this is better than what we've got.
Can't agree more!
True, but you can easily implement this yourself now with this new operator!
const result ?= funcThatCanFail();
if (result[0]) console.error("error");
else console.log(result[1]);
All of these things can be implemented with current JS. Write a factory/decorator function that returns a proxy with an Apply handler that uses try/catch and then returns an error or a result (based on the try/catch), then do a switch based on instanceof the resulting object. Then decorate any function you want to make it return an optional result. JS is super flexible without having to add new features, and we should be using the existing ones over adding new ones to make it like other languages.
@@etherweb6796 🤢🤢
It's like Go's error handling but with JavaScript's flair.
yep.
Thought the same thing.
Damn, this is actually amazing. One of the few useful things missing in JS will be added natively, no need to write try-catch wrappers that do this 😄
Imagine the code after that statement. What logic it would be required to handle error case and non error case? If-else? Isn't the same?
>Don't Need Anymore
>Proposal under active development
😢
>don't need anymore **with this**
@@russellchido but you don't have *this* since it's not released.
@@andrewk2756learn English language
In it's current state, not being considered
Here are my thoughts:
- This is obviously inspired by Go.
- We use try/catch because we don't know if a function can throw an error or not. This proposal doesn't solve that problem. It kinda just adds an easier way to use try/catch but for individual functions. So instead of try {a(); b(); c()} catch (error) {...}, we will have let [errA, resA] ?= a(); [errB, resB] ?= b(); [errC, resC] ?= c();, which is equivalent to try {a()} catch (errA) {}; try {b()} catch (errB) {};try {c()} catch (errC) {}.
- Without knowing if a function can throw or not, you would have to use this new operator for pretty much every function call unless you absolutely know that the function can not throw.
It's still a step in the right direction though.
you could just do
const [err, res] ?= (() => {a(); b(); c();})()
But it's better to handle errors individually, because you know exactly what failed
@@CypekehYeah. you are right. the mentioned way is really awesome
@@Cypekeh That's a cleaner way to write it for sure, but it is exactly the same as doing try/catch in the first way I wrote it. It's just syntactic sugar and it doesn't solve the underlying problem.
@@Voidstroyerto be fair you just summed up JavaScript 😅
@@bricecarpentier5817 Lol you know I was thinking the exact same thing as I was writing my comment. The underyling problems of Javascript can't be solved anymore so they are just focusing on how to get developers to write prettier code.
You can try out the new operator by cloning this repo:
github.com/ipenywis/safe-assignment-operator-demo
It's funny; LOTS of people complain about Go's error handling being verbose, and now this proposal is suggesting to mimic Go's behavior!
Go's error handling is very nice actually. You know that something returns an error and you know how it should be handled and you don't have to worry about it taking down your system.
For sure, forgot to mention that I'm personally not part of the "LOTS of people" I mentioned 😉
It’s very verbose, a Result generic type with syntax support in the language will always be superior
You know what. ?? you are funny.. I think its really a nice feature.
Also LOTS of people don't handle errors at all, then you have to deal with it either as a user, or as a developer who's thrown into that project to fix it :D
Looks a good alternative to try-catch
There's another proposal that comes into play with this. If you don't want to accept a value you will be able to use the keyword 'void' instead, like this:
const [void, result] ?= await fetch(...)
(why? Readability. And the current solution of just skipping bindings causes some real issues in combination with trailing commas. Like does "const [,,] = arr" try to get two or three values? Could be both.)
(edit: I forgot the question mark 🤣)
This is what we needed for so long!
This is SO good. I never understood the concept of try/catch anyway. Like, errors/exceptions are thrown on a expression or statement level. Then why is handling these done on a BLOCK level instead? That's a completely different context. That never made sense to me.
JavaScript keeps making us surprised!
More weird syntax is incoming!
It's still a draft. In the meantime you can do this:
```javascript
const attempt = (operation) => {
let result = null;
let error = null;
try {
result = operation();
} catch(err) {
error = err;
}
return [error, result];
};
const attemptAsync = async (operation) => {
let result = null;
let error = null;
try {
result = await operation();
} catch(err) {
error = err;
}
return [error, result];
};
```
you can await non-promises and have only one wrapper function
@@vsDizzy Marking a function as async when it doesn't perform any asynchronous operations is considered bad practice because it can lead to unnecessary confusion for those reading the code and propagate the need to handle these functions with async/await, adding unnecessary complexity.
@@rafageist i see
Wow. This is amazing. Will make live easier for devs.
According to the proposal the error go first, because a programmer can forget about the error, if it'll be the second element of the cortege? Here is the qoute:
"If someone is using ?= as their assignment operator, it is because they want to ensure that they handle errors and avoid forgetting them. Placing the data first would contradict this principle, as it prioritizes the result over error handling."
If I already use the operator "?=", I already know their might be an error. Why would I forget about it?
Another qoute:
"In Go, the convention is to place the data variable first, and you might wonder why we don't follow the same approach in JavaScript."
I suspect most other languages would go for similar approach - data go first. Why JS should be an different? It only adds confusion, especially for those devs who use several languages in on project and constantly switch between them.
Let's also not forget about multiple JS libs that use data first approach as well.
Addind to that, even IF you forget it, i'm sure this is a very simple lint option to create and add to the project
@@teamadostamine9657you wouldn't even need a special lint rule for this
The typescript linter would complain if you used the unknown error value instead of the typed data value in the wrong places
There's already precedent in the Either monad that places the error in the Left. But other than that, I think in JS you'd be able to write "var [result] ?= blah();" and forget about the error if the result is first, while "var [_, result] ?= blah();" makes you explicitly discard the error value.
Pedantic: both the error and the result are data, so it actually doesn't break the paradigm 🙂
This sorta thing is cool, but it also makes me kinda sad because we can already do exactly what this does without this operator, and just a few lines of JS. I see other comments saying "we should have a Rust style Ok/Err Result syntax added too". This just makes me feel like people don't write JS anymore - Both can be achieved quite easily:
// Implementation
class Ok {
constructor(data) {
this.result = data
}
}
class Err {
constructor(data) {
this.error = data
}
}
function makeOptional(func) {
if (typeof func !== 'function') throw Error("Can't make a non-function object optional");
return new Proxy(func, {
async apply(target, thisArg, args) {
try {
const ok = new Ok(await func.apply(thisArg, args));
return ok;
} catch (error) {
return new Err(error);
}
}
});
}
// End Implementation
// Demonstration
const optionalFetch = makeOptional(fetch);
// ?= Style error handling
const { error, result } = await optionalFetch("/index.html");
if(error) {
console.error('Error fetching index.html', error)
} else {
console.debug('Fetched index.html', result);
}
// Rust Result style handling
const Result = await optionalFetch("/index.html");
switch(result.constructor.name) {
case 'Ok':
console.debug('Fetched index.html', Result);
break;
case 'Err':
default:
console.error('Error fetching index.html');
}
// End Demonstration
It would be a very good approach, I hope they release this.
I don't think there's anything wrong with try-catch or using Promise.catch. I have mixed feelings about this operator. I'm not sure I'll be motivated to use it. How do you determine there's an error? Are you going to use if(error)? With try-catch, you have different blocks dedicated to normal flow and error handling. This blurs that line. Readability might be an issue
Before that we would need a "Symbol.doesError" added to all functions in JavaScript that can throw an error s.t. we can actually detect which ones need error handling.
In the proposal examples, they should really be setting the cause in the constructors of their new errors. People often forget to do that, it hides the original error
It's like error handling in go, but there error is the second argument. I think it's completely useless for js, since nobody is using fetch in place, usually it's a class or function wrapper for http calls, or axios.
One more thing: almost everybody loves to catch and throw in js, so this one will be a dead feature anyway, it can make sense if js will ban try/catch which will never happen.
If this puts pressure on TypeScript to treat errors as normal values with types, I'm all in!
good morning js, thanx bro for this great content
I like this. Not all exceptions should make my code panic.
This is a very bad idea. Exceptions are one of the worst parts of js, you can throw literally any value and the language has no mechanism of only catching a specific kind of error.
It seems like the idea behind this proposal is just syntax sugar for a Result mechanism, but basing it on exceptions means you can't know what the type of the error actually is.
It also encourages you to write more code that throws exceptions so you can use the pretty new syntax, which is just making the problem worse.
I curious why not returning objects like
const {error, result} ?=...
With deconstruction, you can pick the parameters you need and don't stick to the parameters order, which is always a source of dummy errors.
And I'm kind-of sceptical on "the main point" which is force to handle errors.
Why should I? In most cases, I'm primarily concerned with "do I have required data or not?" and branch my logic accordingly.
Error message are good for debutting\logging purposes, and yeah, it's better to have them, but why force?
Easily accessible error message without the mess of try-catch will bump the error handling to the moon already.
Other outcomes about code organisation, variable scope are much valuable
Like golang. But why not error is the second parameter?
Why they dont put the error as second value of result array? I think wuold be more convenient.
I like this approach better than using try-catch blocks, but it's just another way of writing JavaScript. I mean that since we have to maintain compatibility with previous versions of JavaScript, there are different ways of programming to solve the same problem. And we have to learn to read and write in the ways we like and the ones we don't in order to be able to contribute our solution to different projects. But it's the JavaScript way.
This wouldn't replace try/catch even if we did not care about backwards compatibility.
It is not equal to a try/catch block, since a try/catch block can contain multiple lines of code, aka multiple statements.
To imitate such behaviour with this operator you'd have to make an immediately invoked function that has the multiple statements.
e.g.
const [error, data] ?= (()=>{
// statement 1
// statement 2
})();
this is beautiful but I think if they can add multiple return values from a function like golang it will do the trick.
does this feature gives ability to use promise in synchronous function?
Kind of like the callback signature
is like Golang of await-to-js/ts (older libs async await wrapper for easy error handling)
Thank you for the video, 👍
So little bit confused as low level js developer , Can Someone guide me what is proper way of using try and catch beside simple usage and how to handle the exceptions ?
Actually, it seems that using ?= leads to implicit error ignoring.
There is an issue with catching falsy or nulish exceptions
And finally, the Polifill doesn't polifills. Syntax couldn't be polifiled ,and Symbol.result is excessively used in this proposal.
I think this proposal doesn't have chances to be ever approved
I like it
It would make the code Golang-esque, which is nice.
what theme are you using?
Just use the Either monad! It’s actually more fp style
I always create a little helper/wrapper function -- which I put in an object so I can call it `safe.ly()` 😁 -- that does exactly this for any promises. It would certainly be nice to have it build into the language.
(To be clear on my version: it lets you do something like `const [response, error] = await safe.ly(somePromise(...))` . And is TypeScript safe. It's *so* nice not having to chain `.then.catch` and also not having to `try...catch...` around every promise. But I also specifically like having the error be second, to be able to ignore errors/rejections if desired -- for future handler implementation later -- without them bubbling up, simply by declaring a one-element destructuring. I understand why they want to do it the other way around, though.)
This will be great
Does any one know what are the possibilities of this becoming a real feature of JavaScript? I simply loved it!! Even if there is a chance of it becoming a feature of the language, i assume it would take several years, right? 😢
Not ideal for functional programming but curious to see how it plays out
What is the actual code under the hood...
that would be soo cool
try/catch catches all errors, this proposal catches the specific error from the current async function
It caches any error thrown inside the target function. Any thrown exception.
Almost like Lua's protected calls.
Why [error, result] and not [result, error]?
Really cool , i like your content bro , next time course about react motion
Ty dude! Hopefully soon
Thank you a lot 💪
I simply dont understand the main reason they invented it, I think new feature should simplify code, and by that I mean make it shorter, so if my try&catch function has 10 rows the new operator ?= has to do it in 5 rows or still UNDER 10. But this looks pretty much the same length.
Biggest advantage I see is when coupled with typescript. In typescript you can just ignore thrown errors but with this you have to either handle the error or explicitly pass it up in the call chain.
This is really cool
I usually do:
```
let error
const value = await something().catch(e => void (error = e))
```
Let's gooo! errors as values ftw
Everyone is slowing turning into rust/go
I want this so bad
Alright fine, but why error is first?
github.com/arthurfiorette/proposal-safe-assignment-operator?tab=readme-ov-file#why-not-data-first
Because they didn't want to just copy homework.
I felt like coding JavaScript when coding go, now I feel like coding go when coding JavaScript 😅
Typed catching would be preferable
So Go is the way to Go?
This should be the new javascript slogan
and then you exchange a try catch for a workaround and an if. It's the same thing with other makeup.
In js they try to do like in golang, and golang is already thinking about a new alternative like in zig
YESSSS!!! ERRORS AS VALUES!!! As the lord intended
oh, it looks more like functional aproach without pipe.
If error !== null 😂
Is still useful because null consider as 0 so - if(error) return Error
You don't understand it's joke from GO)
😂 if I worked recruitment at a company and a candidate wrote that in front of me there's no chance they'd get hired
Great content. BTW, you sound a little like walter white's son.
If only TS had native support for errors as values like rust or zig.
try/catch in javascript is ugly, because you have scope in try block, and whatever you declare here, you can't access after.
So, this potentially can remove annoying try/catch in a codebase entirely, without needing wrappers around native fetch, for example.
Heavily inspired by Go, I see
That’s syntactic sugar, but I’d prefer to be able to see if a function throws like in Java and be forced to handle the throw 😅
At least we should know if it throws, oftentimes you want an error to bubble up to the top of the request handler and just log and/or return an error response.
12:40 "...imagine having 3 or 4 levels try-catches one inside of another...."
Average Java engineer: "first time?"
is it same issue in Java?
@@nivethan-me Well, first of all, Java is built in such a way that if a function has a chance to throw, it must be declared as such - this happens with the built in language primitives too. So, the developer knows if something throws. This leads to funny chains of try-catches which is fun to think about and a living hell to work with. But on the other hand, things do not go haywire and the applications do not crash in an unexpected way. Most of the time.
ah finally let's 'GO'
I love this
Yeah it's the Go's way, it's easy to handle errors.
Dont be happy, stage 0 proposals can take 10 years or more to get to the actual JavaScript and some despite being good never get to JavaScript
Go always kept two cups on the bedside table. One cup had water, while the other was always empty.
Rust was very puzzled and asked, "Why do you keep two cups here all the time?"
Go replied, "Because I need to drink water when I wake up at night."
Rust then asked, "But why do you need an empty cup?"
Go responded, "What if one day I wake up and don't feel like drinking water?"
Great
next propose "You don't need to javascript anymore ..." :)
I hate the multi value return. Use a Result type.
I wish this would get into Java, and by Java, I mean Java 8 or 11, because no one uses later versions. Exceptions are the bane of what little terseness the language has.
Crazy
bro, it's a proposal
This is waaaaay too close to ??= (already shipped) for it to be any close to be accepted...
Plus, it's not needed by any good devs ;)
I think this should be in all programming languages, Like it is already in golang 😅
Instead of having bazillion try catch, we have bazilion err != nil
i dont like it returns a tuple and not a union
Union??
@@squishy-tomato yeah but yr variable name looks weird
errOrResult
This is an awful proposal. The nice thing about try catch is that it makes it explicit that you are handeling errors. this proposed operator just makes the error handling less explicit.
JS become GO
I think this idea is stolen from golang, because in golang functions can return two values data and error the same idea but with a tuple , yeah kts great so you can handle errors in local not in global no need for one try catch but you will have opportunity for more try catches for more flexibility in error handling
This looks similar to the one in go but this kind of pattern exist since forever. In C there's error codes. In most functional programming languages like Haskell, Scala, instead of try catch they use a monadic approach which is using Either, in Rust there's something similar also called Result. Personally I think this is a superior way of handing errors instead of try catch especially using monad/functor but that's a topic for another day
same in .net, java and rust. so it's not really stolen from go
This is JavaScript, how is it enforcing the handling of the error? Because, unlike Go, you can assign variables and not use them. This doesn’t make any improvements to the language, it just means more syntax and another way to do the same thing as before.
JavaScript needs to have a new mode that would force variable usage. Additionally, it would be nice for all languages to have some kind of syntax to indicate that an error could be returned from a function, this would provide information immediately when calling the function. I like the idea of function names ending with a symbol, like “?”, where a function named “fetch?” would be expected to have errors in certain cases.
I think this proposal is awful.
It is not clear enough from a glance what ?= does, and when I first saw it, replacing try-catch was my last expectation.
Also, changing the output, just because you changed the assignment operator, is going to cause a lot of confusion and is very human error-prone, especially when converting an existing codebase to use this.
Javascrypt looking a bit like Rust
LGTM !
The assignment operator should not have the responsibility of flow control
throw null
If (error !=== null) 😅
JavaScript (Go edition)
like Golang do !, hey JS stop cheating
your opinion * 2