You Don't Need Try/Catch Anymore With This New Operator

#javascript #ecmascript
Read the new safe assignment operator proposal:
github.com/art...
Try out the operator:
github.com/ipe...
🎉Our Newsletter is live! Join thousands of other developers
islemmaboud.co...
🐦 Follow me on Twitter: / ipenywis
-- Special Links
✨ Join Figma for Free and start designing now!
psxid.figma.co...
👉 ✨ Join Figma For Professionals And Start Designing with your Team ✨
psxid.figma.co...
-- Watch More Videos
🧭 Build Login/Register API Server w/ Authentication | JWT Express AUTH using Passport.JS and Sequelize
• Build Login/Register A...
🧭 Turn Design into React Code | From prototype to Full website in no time
• Turn Design into React...
🧭 Watch Tutorial on Designing the website on Figma
• I Design a onecolor We...
🧭 Watch Create a Modern React Login/Register Form with Smooth Animations
• Create a Modern React ...
🧭 Debug React Apps Like a Pro | Master Debugging from Zero to Hero with Chrome DevTools
• Debug React Apps Like ...
🧭 Master React Like Pro w/ Redux, Typescript, and GraphQL | Beginner to Advanced in React
• Master React Like Pro ...
🧭 Learn Redux For Beginners | React Redux from Zero To Hero to build a real-world app
• Debug React Apps Like ...
🧭 Introduction to GraphQL with Apollo and React
• Introduction to GraphQ...
🐦 Follow me on Twitter: / ipenywis
💻 Github Profile: github.com/ipe...
Made with 💗 by Coderone

[@CoderOne]

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

[@etherweb6796]

This can already be done without a new operator with vanilla JS.

[@anasouardini]

I liked treating errors as values as soon as I encountered it in Golang.

[@DaPaBe1999]

Amen

[@GJCloud]

Still better then try catch

[@user-bp8hd6kr3d]

In js they try to do like in golang, and golang is already thinking about a new alternative like in zig

[@--bountyhunter--]

wassup akhi. hry? WP sucks btw

[@voltflake]

zig has op error handling

[@andrewk2756]

>Don't Need Anymore >Proposal under active development

[@user-lq7xz1th4x]

😢

[@russellchido]

>don't need anymore **with this**

[@andrewk2756]

@@russellchido but you don't have *this* since it's not released.

[@theseangle]

​@@andrewk2756learn English language

[@michawhite7613]

In it's current state, not being considered

[@rjtdas]

It's like Go's error handling but with JavaScript's flair.

[@eduardmart1237]

yep.

[@forinda]

Thought the same thing.

[@TianYuanEX]

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 😄

[@deathineyes]

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?

[@steve-adams]

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.

[@CoderOne]

Can't agree more!

[@Tijme]

True, but you can easily implement this yourself now with this new operator!

[@nicholashendrata]

const result ?= funcThatCanFail(); if (result[0]) console.error("error"); else console.log(result[1]);

[@etherweb6796]

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.

[@JiggyJones0]

​@@etherweb6796 🤢🤢

[@farzadmf]

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!

[@chudchadanstud]

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.

[@farzadmf]

For sure, forgot to mention that I'm personally not part of the "LOTS of people" I mentioned 😉

[@lack_of_awareness]

It’s very verbose, a Result generic type with syntax support in the language will always be superior

[@Mr.BinarySniper]

You know what. ?? you are funny.. I think its really a nice feature.

[@bring-shrubbery]

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

[@keenanmolver9689]

At my old company we had this same implementation. It was very simple and we called it attempt.

[@VladimirMiroshnichenko64]

with try/catch inside function?

[@Voidstroyer]

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]

you could just do const [err, res] ?= (() => {a(); b(); c();})() But it's better to handle errors individually, because you know exactly what failed

[@Mr.BinarySniper]

​@@CypekehYeah. you are right. the mentioned way is really awesome

[@Voidstroyer]

@@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]

@@Voidstroyerto be fair you just summed up JavaScript 😅

[@Voidstroyer]

@@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.

[@rafageist]

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]

you can await non-promises and have only one wrapper function

[@rafageist]

​@@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.

[@vsDizzy]

@@rafageist i see

[@quietfox157]

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 🤣)

[@steadexe]

This is what we needed for so long!

[@henrique-work]

Looks a good alternative to try-catch

[@quietfox157]

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.

[@crowleyeusford7886]

JavaScript keeps making us surprised!

[@CoderOne]

More weird syntax is incoming!

[@ReasonX3]

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.

[@teamadostamine9657]

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

[@arjix8738]

​@@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

[@mrwensveen]

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 🙂

[@shahbaz_shueb]

Wow. This is amazing. Will make live easier for devs.

[@eugeneponomarov7429]

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.

[@joshiboshi6140]

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 😅

[@theairaccumulator7144]

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.

[@squishy-tomato]

I feel like I'm 1 in 100, but I don't think errors as values are better than exceptions on their own. Take go. Most of "error handling" code lines in Go consists of "if err != nil { return err }" scattered all over the code base to replicate the same bubbling-up behavior an unhandled exception creates. Meaning, in a try-catch scenario, if you did nothing, an error raised would automatically bubble up to the caller *without adding these two check and return lines*; hell, without even adding a try-catch. The problem is not exceptions per se; just like the "solution" is not errors by values. The problem lies on discoverability: in many languages it's not trivial to check which exceptions a function raises. Returning the error by value does NOT address that, as the error can still be *anything*. You can't properly handle something without knowing what it is. But this is more than an incorrectly addressed issue in my view. Errors by value have inherent flaws that are not easily addressed in a dynamic language like JS. Errors by value work wonders in Rust because the compiler is very pedantic about unwrapping results before processing them. There's nothing even close to that in that JS landscape, so at first glance this feels like a half-baked proposal at best, and something that will clutter JS code bases with checks analogous to err != nil at worse. But perhaps the worse side-effect of errors by value is that it's ridiculously easy to ignore errors. If you have an unhandled exception, it will crash your code. Making the program enter an undefined state with exceptions requires an explicit catch() that doesn't re-raise it. Making the program enter an undefined state with errors as values is as easy as doing nothing (i.e. *not* using the error value).

[@pokefreak2112]

I think the if err != nil and similar ugly repetitive code patterns are actually a feature because it encourages you to think about handling your errors more to keep as much of your code error-free as possible so it doesn't look ugly. Exceptions are unobtrusive. At best it's a function annotation and at worst (javascript) it's literally invisible. It's easy to ignore them and end up with a complex monstrosity. For similar reasons I don't think spread syntax was a good idea. No one is going to use iterators as intended because [...list].map() is more ergonomic than a bespoke loop. The pretty syntax essentially encouragers spamming memcpy, similar to how exceptions encourage ignoring errors. Other than that I 100% agree.

[@patrickramos1748]

Exactly what i had in mind. 98% of the time i want the error to just bubble up, at least in application code. I like rust's Results because of this, you can easily do both, matching on the result, or doing `result?` to bubble the error up.

[@pokefreak2112]

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.

[@Jamiered18]

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

[@marcusradell7544]

If this puts pressure on TypeScript to treat errors as normal values with types, I'm all in!

[@karamuto1565]

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.

[@taquanminhlong]

If error !== null 😂

[@senselessplays]

Is still useful because null consider as 0 so - if(error) return Error

[@user-is3yh5ik6t]

You don't understand it's joke from GO)

[@theairaccumulator7144]

😂 if I worked recruitment at a company and a candidate wrote that in front of me there's no chance they'd get hired

[@babatundeojerinde]

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

[@etherweb6796]

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

[@CoderOne]

You can try out the new operator by cloning this repo: github.com/ipenywis/safe-assignment-operator-demo

[@DiogoLScarmagnani]

It would be a very good approach, I hope they release this.

[@elontang2358]

Like golang. But why not error is the second parameter?

[@mfpuente]

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.

[@arjix8738]

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 })();

[@jfftck]

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.

[@okadz7037]

good morning js, thanx bro for this great content

[@thejimmylin]

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?"

[@ugentu]

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

[@ErnestOak]

Kind of like the callback signature

[@macon5696]

does this feature gives ability to use promise in synchronous function?

[@carloshenriquefonseca8459]

Why they dont put the error as second value of result array? I think wuold be more convenient.

[@oussamasethoum1665]

this is beautiful but I think if they can add multiple return values from a function like golang it will do the trick.

[@JoseHenrique-xg1lp]

I like this. Not all exceptions should make my code panic.

[@shyrogan2341]

Everyone is slowing turning into rust/go

[@dimitro.cardellini]

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

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 ?

[@gigas3651]

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

[@m2g5]

is like Golang of await-to-js/ts (older libs async await wrapper for easy error handling)

[@jorgehabib3933]

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? 😢

[@НаильШайхинуров-п7л]

Just use the Either monad! It’s actually more fp style

[@superlogic255]

It would make the code Golang-esque, which is nice.

[@karakaz]

Not ideal for functional programming but curious to see how it plays out

[@altermunmis]

I felt like coding JavaScript when coding go, now I feel like coding go when coding JavaScript 😅

[@olhoTron]

Why [error, result] and not [result, error]?

[@mohanedomer9081]

that would be soo cool

[@papa_ethan]

try/catch catches all errors, this proposal catches the specific error from the current async function

[@CoderOne]

It caches any error thrown inside the target function. Any thrown exception.

[@xenon4602]

what theme are you using?

[@ransomecode]

I usually do: ``` let error const value = await something().catch(e => void (error = e)) ```

[@vitorhideyoshinakazonebati7531]

YESSSS!!! ERRORS AS VALUES!!! As the lord intended

[@MyGeorge1964]

What is the actual code under the hood...

[@chrisfelicien]

This will be great

[@muratcemyalin]

next propose "You don't need to javascript anymore ..." :)

[@sudeep.g]

Let's gooo! errors as values ftw

[@zebraforceone]

Typed catching would be preferable

[@IceMetalPunk]

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.)

[@RatherBeCancelledThanHandled]

This is really cool

[@algonix11]

and then you exchange a try catch for a workaround and an if. It's the same thing with other makeup.

[@offgridvince]

I like it

[@maximenadeau9453]

If only TS had native support for errors as values like rust or zig.

[@vicca4671]

Almost like Lua's protected calls.

[@user-bp8hd6kr3d]

In js they try to do like in golang, and golang is already thinking about a new alternative like in zig

[@nanonkay5669]

Heavily inspired by Go, I see

[@zenoviyfil]

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.

[@Robert-yw5ms]

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.

[@wojciechosinski5927]

Alright fine, but why error is first?

[@CoderOne]

github.com/arthurfiorette/proposal-safe-assignment-operator?tab=readme-ov-file#why-not-data-first

[@arjix8738]

Because they didn't want to just copy homework.

[@shekharsikku]

I think this should be in all programming languages, Like it is already in golang 😅

[@gamingwolf3385]

Really cool , i like your content bro , next time course about react motion

[@CoderOne]

Ty dude! Hopefully soon

[@gamingwolf3385]

Thank you a lot 💪

[@PhilipAlexanderHassialis]

12:40 "...imagine having 3 or 4 levels try-catches one inside of another...." Average Java engineer: "first time?"

[@nivethan-me]

is it same issue in Java?

[@PhilipAlexanderHassialis]

@@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.

[@justafreak15able]

ah finally let's 'GO'

Instead of having bazillion try catch, we have bazilion err != nil

[@elvispalace]

bro, it's a proposal

[@dxbgaming4813]

Yeah it's the Go's way, it's easy to handle errors.

[@Zeero3846]

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.

[@zbynekriha]

oh, it looks more like functional aproach without pipe.

[@Mestre_tainha]

Great content. BTW, you sound a little like walter white's son.

[@KonradZielinski]

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.

[@talhaibnemahmud]

I want this so bad

[@michawhite7613]

I hate the multi value return. Use a Result type.

[@cotyhamilton]

I love this

[@OneBrighDay]

Crazy

[@MrEliteXXL]

Great

[@dodgeclub7162]

JS become GO

[@chess4964]

So Go is the way to Go?

[@CoderOne]

This should be the new javascript slogan

[@rafageist]

The assignment operator should not have the responsibility of flow control

[@fastneasy]

soon javascript will look like cuniform

[@Georgggg]

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.

[@everyhandletaken]

LGTM !

[@nomadshiba]

i dont like it returns a tuple and not a union

[@CoderOne]

Union??

[@squishy-tomato]

@@CoderOne a union would have a single returned variable that could either be of a type "Error" or something else, instead of [result, error]. I agree; it's a better way to handling it, because error and result are more often than not mutually exclusive.

[@tjtjtyjtyjt]

@@squishy-tomato yeah but yr variable name looks weird errOrResult

[@gamingwolf3385]

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

[@impostor8984]

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

[@RaZziaN1]

same in .net, java and rust. so it's not really stolen from go

[@ralkey]

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.

[@EduarteBDO]

Javascrypt looking a bit like Rust

[@0X_0LL4R-]

like Golang do !, hey JS stop cheating

[@cxarra]

JavaScript (Go edition)

[@Robert-yw5ms]

throw null