4 ms·
1) This was possible in node 7 2) A request can fail and can timeout. 3) Writing to a file can fail. And you get the idea. Don't omit error handling. Error h
by partycoder 9y ago
1) This was possible in node 7
2) A request can fail and can timeout.
3) Writing to a file can fail.
And you get the idea. Don't omit error handling. Error handling is business logic too.
Being relaxed around error handling is the recipe for cascading server failure.
- nailer 9y agoI'm just getting started with async/await (like most people I stick to LTS releases) so please forgive the lack of error handling in the demo code!
- partycoder 9y agoAs someone who spends all day volunteering in Stack Overflow I hope people providing examples were a little bit better at emphasizing error handling. You should see the destructive effects of bad examples there.
- nailer 9y agoYou're welcome to add it.
- ryeguy 9y agoOh please. The point of the post was to illustrate the feature to those wondering "what's async/await?", error handling would be complete noise for that purpose.
- partycoder 9y agoI would argue with you, but I don't really have to prove you wrong. You will eventually prove yourself wrong, since deemphasizing error handling goes wrong very quickly.
- danneu 9y agoIn their snippet, errors would be handled altogether on the promise you get from `getJeansAndSaveThem()`. You don't have enough information to be outraged at the toy example.
- partycoder 9y agoAnd that's a very implicit way of handling the error. Implicit behavior is good when you are encapsulating stuff (e.g: I don't need to know about the details of internal combustion engines, just pushing on the accelerator of my car so it moves forward). But in this case encapsulation is a leaky abstraction that just makes the diagnosing of an error more cumbersome.
- kabes 9y agoNote that node 8.0.0 is not LTS. Node 8.x will be an LTS release around October.
- deleted 9y ago[deleted]
- minitech 9y agoOne of the nice things is that you can just let async functions fail and they won’t throw asynchronously and kill the process. So no, error handling isn’t important to include in a small example.
- NoInkling 9y agoPreviously that characteristic was also a massive pain point for debugging Node apps though - neglecting error handling would result in silently swallowed errors and leave people (particularly newbies) scratching their heads. Then they added unhandled rejection warnings by default, and all was ok again - but I see why someone might insist that all examples have error handling.
- minitech 9y agoThat’s not something that should be handled inside an async function (and therefore not in this example). If you don’t want to continue a promise chain, terminate it: .catch(error => { process.nextTick(() => { throw error; }); })
- partycoder 9y agoYou want to use setImmediate rather than process.nextTick.
- minitech 9y agoMmm… no, I didn’t want to. Why do you say that?
- Noseshine 9y agoObviously the example code is inside another function - `await` can only be used inside a function marked with `async`, which always returns a promise. That means error handling may not be necessary inside that function. Errors are caught automatically and returned to the caller as rejected promise! You need error handling at the top level but not necessarily inside each function.