Hacker News new | past | comments | ask | show | jobs | submit login

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.




I'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!


Note that node 8.0.0 is not LTS. Node 8.x will be an LTS release around October.


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


You're welcome to add it.


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


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.


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


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:

  .catch(error => {
    process.nextTick(() => { throw error; });
  })


You want to use setImmediate rather than process.nextTick.


Mmm… no, I didn’t want to. Why do you say that?


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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: