4 ms·

.then().catch() is basically just a fancy wrapper around try..catch, so I'm not entirely sure what the example is supposed to show? With async that code would

.then().catch() is basically just a fancy wrapper around try..catch, so I'm not entirely sure what the example is supposed to show? With async that code would be equivalent to something like: try { const response = await fetch(...); const data = await response.json(); if (data.errors) { handleErrors(data.errors.code); } else { handleResponse(data.response); } } catch (error) { error; // handle error }

amelius 8y ago
There's a difference: .then().catch() is worse because you can forget the .catch() part, and your error will be discarded unless you set up a global error handler (ugly because now the error will not bubble up properly). Not so with try ... catch.
- davnicwil 8y ago
  Isn't forgetting to chain a .catch() just the equivalent of completely forgetting the 'try' block in async/await code though? Seems like in both cases, the cause is the same: you weren't aware or forgot that the async logic might throw, and so you don't write code to handle it.
  - Doxin 8y ago
    Sure, but the result is different. Missing out a try/catch will make your program crash/log an error/whatnot when the error happens. missing out a .catch() might put an error in the console sometimes. Fail fast is an important principle, but in my opinion fail hard is fairly important too. If your program explodes every time a bug happens you're more likely to fix them. If it merely doesn't do the thing it's supposed to it's easy to miss and easier to ignore.
    - btschaegg 8y ago
      > Fail fast is an important principle, but in my opinion fail hard is fairly important too. If your program explodes every time a bug happens you're more likely to fix them. If it merely doesn't do the thing it's supposed to it's easy to miss and easier to ignore. Indeed. Having witnessed a couple of disastrous mishaps because someone didn't properly check return codes in their C code, I'd argue it's even worse than that. You can't predict the myriad of wrong ways your System will behave after an ignored error because things that were implicitly taken for granted aren't true anymore. And those are the types of errors that come with a great cost since a) you might not be aware of them the next few months and b) they are usually not easy to find in an automated fashion.
      - Doxin 8y ago
        Right. Not catching an error is as bad as magically catching and ignoring all errors, and for the same reason: The state of the system is clearly unknown. Specific actions must be taken in response to the error to recover. It's generally safer to kill the entire system than to keep chugging on after an error without a tailored error handler.
    - davnicwil 8y ago
      What you say is true and I don't disagree with it, but we're talking about different levels of abstraction. Yes, at a lower level there is a technical difference, but if you zoom out far enough, the result is not different, i.e. in both cases the feature does not work. I understand and agree with what you are saying about failing fast and hard being more convenient to catch bugs, as an engineer, but then we get into what is a bug and what can be ignored? If the result is a mission critical feature breaking, you can't ignore that. Inversely, if you can ignore it, then it isn't mission critical. So my point was, at a higher level of abstraction they are the same thing. The cause is forgetting to handle an Error in your code, the effect is a feature breaking. Regarding that cause then, the OP was saying that it's easier to forget chaining a .catch(), but that is only assuming that you'd actually remembered to use a try in your async/await code, i.e. you are aware of the fact it might throw. I can't think of many times where I have been aware something might throw and forgotten a .catch(), but for some reason would have remembered to wrap the call with a try, were it async/await code. I guess I am saying it's unclear to me how try/catch helps one remember to handle Errors, over .catch(). Seems like the syntax is not the issue, the issue is not being aware or ignoring that the code might throw in the first place. Obviously, this is all dependent on context and application and both perspectives are 'right' for different scenarios.
      - Doxin 8y ago
        They are not the same, not even at a higher level. The default action is different, ignoring errors by default is dangerous. Sure in many cases you'd like to catch the error and ignore it, but that has to be a conscious decision someone should have at some point thought about.
- KenanSulayman 8y ago
  If you use async/await and the awaited promise throws, the exception will become a hard exception in the context of the async / await (i.e. disrupt the control flow and exit).
- Flimm 8y ago
  Modern Node and most modern browsers will print a warning to the console when this happens. See my answer on Stack Overflow: https://stackoverflow.com/a/52061395/247696 https://stackoverflow.com/a/52061395/247696

amelius 8y ago

There's a difference: .then().catch() is worse because you can forget the .catch() part, and your error will be discarded unless you set up a global error handler (ugly because now the error will not bubble up properly). Not so with try ... catch.

davnicwil 8y ago
Isn't forgetting to chain a .catch() just the equivalent of completely forgetting the 'try' block in async/await code though? Seems like in both cases, the cause is the same: you weren't aware or forgot that the async logic might throw, and so you don't write code to handle it.
- Doxin 8y ago
  Sure, but the result is different. Missing out a try/catch will make your program crash/log an error/whatnot when the error happens. missing out a .catch() might put an error in the console sometimes. Fail fast is an important principle, but in my opinion fail hard is fairly important too. If your program explodes every time a bug happens you're more likely to fix them. If it merely doesn't do the thing it's supposed to it's easy to miss and easier to ignore.
  - btschaegg 8y ago
    > Fail fast is an important principle, but in my opinion fail hard is fairly important too. If your program explodes every time a bug happens you're more likely to fix them. If it merely doesn't do the thing it's supposed to it's easy to miss and easier to ignore. Indeed. Having witnessed a couple of disastrous mishaps because someone didn't properly check return codes in their C code, I'd argue it's even worse than that. You can't predict the myriad of wrong ways your System will behave after an ignored error because things that were implicitly taken for granted aren't true anymore. And those are the types of errors that come with a great cost since a) you might not be aware of them the next few months and b) they are usually not easy to find in an automated fashion.
    - Doxin 8y ago
      Right. Not catching an error is as bad as magically catching and ignoring all errors, and for the same reason: The state of the system is clearly unknown. Specific actions must be taken in response to the error to recover. It's generally safer to kill the entire system than to keep chugging on after an error without a tailored error handler.
  - davnicwil 8y ago
    What you say is true and I don't disagree with it, but we're talking about different levels of abstraction. Yes, at a lower level there is a technical difference, but if you zoom out far enough, the result is not different, i.e. in both cases the feature does not work. I understand and agree with what you are saying about failing fast and hard being more convenient to catch bugs, as an engineer, but then we get into what is a bug and what can be ignored? If the result is a mission critical feature breaking, you can't ignore that. Inversely, if you can ignore it, then it isn't mission critical. So my point was, at a higher level of abstraction they are the same thing. The cause is forgetting to handle an Error in your code, the effect is a feature breaking. Regarding that cause then, the OP was saying that it's easier to forget chaining a .catch(), but that is only assuming that you'd actually remembered to use a try in your async/await code, i.e. you are aware of the fact it might throw. I can't think of many times where I have been aware something might throw and forgotten a .catch(), but for some reason would have remembered to wrap the call with a try, were it async/await code. I guess I am saying it's unclear to me how try/catch helps one remember to handle Errors, over .catch(). Seems like the syntax is not the issue, the issue is not being aware or ignoring that the code might throw in the first place. Obviously, this is all dependent on context and application and both perspectives are 'right' for different scenarios.
    - Doxin 8y ago
      They are not the same, not even at a higher level. The default action is different, ignoring errors by default is dangerous. Sure in many cases you'd like to catch the error and ignore it, but that has to be a conscious decision someone should have at some point thought about.
KenanSulayman 8y ago
If you use async/await and the awaited promise throws, the exception will become a hard exception in the context of the async / await (i.e. disrupt the control flow and exit).
Flimm 8y ago
Modern Node and most modern browsers will print a warning to the console when this happens. See my answer on Stack Overflow: https://stackoverflow.com/a/52061395/247696 https://stackoverflow.com/a/52061395/247696