16 ms·
You Can Throw() Anything in JavaScript – and Other Async/Await Considerations
- throwaway81523 5y agoI feel like async/await is a huge antipattern in a language like JS. They should have gone for lightweight threads instead.
- junon 5y agoI actually quite like it. Matter of opinion.
- heavenlyblue 5y agoI love this thread, pseudonymous circle of unjustified likes or dislikes of a specific technology.
- creativenolo 5y agoI'm not sure I like this thread.
- isaacimagine 5y agoI love the metacommentary on this thread, in that it matches the pattern of original commentary.
- paskozdilar 5y agoI don't like the metacommentary on this thread so much. The fact that the first two commends are dislike-like and the rest are like-dislike really ruins it for me.
- mariusmarais 5y agoI like how the replies are starting to make the little arrow thing. Reminds me of something...
- deleted 5y ago[deleted]
- jdrc 5y agoGlorified Goto spaghetti
- smt88 5y agoIt is in some languages, but not in JS. It's definitely not good, but it's not goto spaghetti.
- anonymoushn 5y agogoto is fine idk
- junon 5y agoGoto is super helpful in C for error handling. But yes, let's continue parroting the same old rhetoric.
- deleted 5y ago[deleted]
- jdrc 5y agois await better than goto? frankly i prefer the latter
- __ryan__ 5y agoWhy?
- samatman 5y agoI agree and claim the burden is on those who say "it's fine, actually" to rebut the definitive article[async:0] on the subject: [await:0] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... (read it whenever you would like, it's good I Promise). If you've only ever used Javascript, it's tempting to think this is some fact of nature, rather than bad language design.
- johannes1234321 5y agoWhile it is right, that the red/blue distinction is annoying at times it is the consequence out of the event-loop based approach created in 1995. Any other solution would have broken that more. It is assumed that the code we have is single threaded. That not being the case anymore leads to tons of concurrency issues. Right now I know that all my code, till the next await, will run (mostly) uninterrupted by external influence. No locking needed, nothing will change behind my back etc. In a greenfield environment things certainly would look different, but unfortunately we are tied to past decisions till browser vendors decide to create an alternate universe (well, webassembly ...) and that has enough spread to rely on. But for that one would need agreement what that better future would be.
- anonymoushn 5y agoThis isn't true. If you had stackful coroutines or something equivalent, you would be able to do all the things this thing does and you wouldn't have to pepper your callers and callers' callers with "await" whenever you add an operation that may take some time to a function for the first time. We had this in Python and still have it in Lua, C, Zig, and so on, but the world has mostly gone the other way.
- samatman 5y agoI happen to be working on an application which is largely written in Lua and uses the same event loop (libuv) as Node. I can confirm that with careful engineering, application code doesn't have to suffer from the color problem. Fundamentally the trick is to yield after creating a callback, and resume into that callback when the thread has more data to process. A `foo:bar():baz():bux()` chain can pause execution in any of those methods and the user doesn't have to know which (some knowledge of whether this will happen /at all/ is required, only because you need a coroutine since Lua can't yield the main thread). This isn't built-in, need to start with something like BEAM for that, but it's a nice sweet spot.
- ThunderSizzle 5y agoI personally prefer async/await over callbacks or promises. I find the flow better when I can make an Ajax call just await the result, rather than having to implement a success function.
- paskozdilar 5y agoThe "lightweight thread" alternative would probably make the Ajax call blocking, so you could just launch a thread that waits for it to finish, then continues on with the rest of its instructions. The "callback hell" wouldn't exist in the first place. This is exactly what Golang did, and in my honest opinion, it's a breeze of fresh air in the modern mess of processes/threads/asyncawaitcoroutines and all their combinations.
- andrelaszlo 5y agoI'm pretty used to seeing strings being thrown. Maybe I am just old?
- Gravyness 5y agoSame, although I always thought it was a terrible practice as I'm always reading error.message or error.stack straight away. And if an error does not have a stack then I will call the police on whoever wrote this shit!
- prmph 5y agoI recently started throwing bare string instead of Error objects, just because of all the Error: prefixes that are prepended to the error message when you throw an Error. It just clutters up the stack trace. More generally I wish there was an Error constructor that automatically records and the function, arguments, and other semantically meaningful information when called. File and line numbers do not make for a pleasant experience when inspecting a stack trace.
- nimbix 5y agoThere was a point years ago when I was surprised to find out that you can throw things other than strings...
- jibbit 5y agosubclassing Error was a mess.. almost 'not supported'. For old times sake.. https://stackoverflow.com/questions/1382107/whats-a-good-way-to-extend-error-in-javascript https://stackoverflow.com/questions/1382107/whats-a-good-way...
- junon 5y agoThat was the norm maybe 15-20 years ago. These days it's a mortal sin to throw from something that isn't derived from Error.
- Tade0 5y agoI think the last time I threw anything else than an Error was in 2012 or so. Old it is I guess - both of us.
- hambes 5y agoPlease, please, please do not throw anything that is not derived from Error. Throwing literals or other things makes error handling so much less predictable, stable and useful. throw/catch is already bad, let's not make it worse than it needs to be.
- onion2k 5y agoNonsense. You can treat Throw like a fancy "goto the nearest catch" if you want to. It works fine.
- shadowgovt 5y agoYes. In every way that goto is considered harmful it works fine.
- smt88 5y agoIf you're using throw for control flow, something is deeply wrong with your code.
- the_other 5y ago`throw` is a control flow instruction. Simply using it at all controls flow within your code. Are you suggesting never to use it?
- giorgioz 5y agoReact 18 is in fact throwing Promises for the new implementation of Suspense working on Server Side Rendering. I found it brilliantly elegant. Throwing a promise in that context means "I'm not done yet and you should display a fallback"
- d--b 5y agoThis sounds interesting, but very error prone, no? - Some code could throw a legitimate error, that would take the place of the promise. - Some code may catch the promise and treat it as if it was an error.
- pavlov 5y agoThis is in context of React components which are functions but only ever executed by the React runtime itself. So there’s no other code that could catch the promise. And if another component throws an error first, that’s what needs to be handled anyway.
- furstenheim 5y agoEslint with standardjs in js is so great, set it up and it will fail if you throw anything different from an error. https://github.com/standard https://github.com/standard
- silverwind 5y agoLink to the actual rule: https://eslint.org/docs/rules/no-throw-literal https://eslint.org/docs/rules/no-throw-literal
- samatman 5y agoJavascript suffers terribly from the lack of asymmetric stackful coroutines. All of this bizarre conflation of responsibility and extraneous keywords in the language, when all that was ever needed was `create`, `suspend`, and `resume`.
- throwanem 5y agoFortunately, this is trivial to correct. Just grab a complete set of Go sources and documentation, hop in your time machine, and set the dial for 1995...