Very nice man. I really like your videos because I always learn something new. You always push things one step further. Thanks.

Wanted to start adapting async/await in my projects instead of promises resolve/reject and was really bothered by the try/catch thing all over the place, though this is perfectly what i was looking for. Thanks Jesse!

@JesseWarden

5 жыл бұрын

You're welcome!

Wow thank you for another follow up to my question in a video form! I feel special! XD

Yay Jesse is back. Great video will keep in mind for future async await scenarios. I personally still prefer promise.then prolly cause I got used to it and I find a lot of people don't have Node 8+

@JesseWarden

6 жыл бұрын

Yeah, at work we support LTS only, so 6.8.1 until recently. That, and after many years, I'm completely used to using promises, and have no need (yet?) for that CSP insanity, so don't use async/await either. I've been using a bit more of Tasks from Folktale, and occasionally Bluebird's helpful methods.

Excellent video! This is fucking revolutionary for me honestly. You're a good teacher.

awesome tutorial man thanks im gonna implement this on backend where there is so many folders and errors to handle

if i want multiple functions , the result will conflict :(

Video request: Would love a video on things you wish you invested the time in to become the experienced dev you are today. (Side note, your unit testing videos have been instrumental for me)

@JesseWarden

6 жыл бұрын

k, uploading...

Informative video. Well done

I'm confused. You replaced try/catch from the beginning of the video with an if/else at the end of the video, and along the way lost the ability to not catch and let a calling method handle the exception.

@JesseWarden

6 жыл бұрын

"the ability to try/catch". This is a feature of many languages. PHP, JavaScript, Java, etc. are very popular, so there is nothing "wrong" with try/catch. However, other languages have newer, and what they perceive as better alternatives. I like what they offer specifically from a code correctness angle as well as easier to unit test. I like to know "did this function work or not" vs. "if it worked, cool, otherwise it exploded". I like Algebra, and like mathematical correctness there, it's either 1+1=2, or 1+2!=2. I like building functions I can depend on vs. ones that "might" blow up, and I sequester them in various try/catch blocks knowing if they blow up, I'll have to go digging to figure it out. Let's take Lua for example (easier to read than Go if you're from JavaScript like me): function datBoom() error({reason='kapow'}) end ok, error = pcall(datBoom) print("did it work?", ok, "error reason:", error.reason) -- did it work? false, error: kapow Unlike Go, Lua gives you the ability to opt-in to this feature. If you call a function using pcall, it's like a built-in try/catch. The unit test for above: ok, error = pcall(datBoom) assert(ok == True, "Function didn't return an error."); // pass 1 line to run, 1 line to test. In JavaScript, depending on your assertion library, you need to setup a Mock or callback. Here's Mocha for example: const datBoom = () => { throw new Error('boom'); }; // and the test const callback = () => datBoom(); expect(callback).to.throw(Error); ... that's just ridiculous on 2 points: 1. Why can't I just call my function to assert if the function worked? 2. This is just 1 function... what happens when it's a class full of these throws deeply nested throughout? It's hard to predict what the code path is. The above vs: const {ok} = datBoom(); expect(ok).to.equal(true); Now, the first complaint people have once they're forced into this style (read newly christened Go devs) is they're suddenly forced to deal with the errors inline. At least with try/catch, you can write what you want to happen in 10 lines, and just wrap the whole thing, knowing "if anything breaks, just catch in 1 place, log out, and debug later". I'm not interested anymore in debugging later. I want to write correct code, from the start, and deal with the potential known errors here and now. Let's design for it. Let's test for it (not TDD, just some level of coverage). Way of life in Go: func datBoom() (err error) ok, err := datBoom() if err != nil { log.Fatal(err) } I didn't "lose" the ability to catch, rather I created pure functions that don't break other functions. They are easy to test, easy to debug, and force people to deal with errors then and there vs. ignore them. I should of been more clear these are tenets of newer languages, as well as borrowing ideals from Functional Programming. I hope this makes more sense.

@jakubrpawlowski

6 жыл бұрын

Another benefit of sureThing is that it composes well with currying. One advice I have for you Jesse is at the beginning of the video like this - do a short real life example - here could have shown some debugging hell caused by catch. Your try catch example doesn't look scary enough! :P

in case of linked multiple promises can't I just wrap the async func inside a then and handle the error with catch ?

How is this an easier way? Instead of having a try/catch block to handle any error of a function, you will now have to insert an if-statement for every single await call. You prevent an unhandled exception, but yet don't handle any error this way.

@JesseWarden

5 жыл бұрын

1. You no longer have errors, only functions that let you know if they worked or not. 2. You no longer have to use try catch. 3. You can unit test by giving a function an input and testing the output; no longer needing to test "if it errors". 4. If you like imperative coding a la Go, Python, or Lua, then you'll love this method with async/await because none of your code needs try/catch. It's easier to follow (which is the draw of async/await for some people).

Firstly, love this. I've been searching the interwebs for an alternative to try/catch for several hours now and never would have thought of this. Is there a decrease in performance with the sureThing() approach? If one were to call Promise.all, map over an array of items, and pass an async/await function as the callback to map, and wrap your promise or fetch in sureThing() would it be slower than the try/catch approach?

@JesseWarden

6 жыл бұрын

No idea about performance, I never do benchmarks. :: millennial voice :: "I heard Bluebird is faster than native promises." Most perf issues using this stuff stems from writing things sequentially when a parallel would of been better. i.e. not using Promise.all. If you don't have to do it in order, don't; create async functions all you wish, just use Promise.all as much as possible. I get, though, doing things in order using await allows you to put a lot of log statements to handle some gnarly async code.

@MrJaminbrad

6 жыл бұрын

Jesse Warden awesome. Great points. Many thanks for the feedback

catch() doesn't need to return a Promise; it can return the object directly.

@JesseWarden

3 жыл бұрын

Totally, it's just more clear what you're doing if you're in a catch and you write "resolve".

@JesseWarden

3 жыл бұрын

Also, returning an error from a catch doesn't always result in an Exception; you need to be explicit and return Promise.reject

WOW! I'm lost.

Hi, what is the name of your theme :)

@JesseWarden

5 жыл бұрын

Monokai Dimmed

@orcunkobal

5 жыл бұрын

thank you

Keep it slow! Please

@dntwantgglplus

5 жыл бұрын

you have total control over the speed of the video playback

Didn’t get it.

@JesseWarden

6 жыл бұрын

Check out how other programming languages do it similarly: jessewarden.com/2017/11/error-handling-strategies.html

please bring your cringe level little down from 9000 so that I can concentrate.