And 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.
Oh 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.
One 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.
Previously 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.
That’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:
Obviously 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.
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.