4 ms·

This article doesn't even touch on the worst sin of JavaScript Promises: they swallow errors and exceptions, which makes them nearly impossible to test correctl

This article doesn't even touch on the worst sin of JavaScript Promises: they swallow errors and exceptions, which makes them nearly impossible to test correctly and makes debugging horrifying (if you even notice anything is wrong.) Promises are a great example with the problems of believing that something good in one language will be good in another. Promises in JavaScript are fighting the language, because JavaScript is fundamentally a collection of isolated but contextual behaviors. Using Agents to encapsulate callbacks is easier to reason about, easier to test, less likely to swallow errors whole, and doesn't have any of the problems laid out in this article. Unfortunately because it isn't a model popular in any other language, it doesn't have the name recognition Promises do.

rictic 9y ago
Can you expand on that? How would an agent-based API propagate exceptions?
yuchi 9y ago
Promises don‘t swallow errors (sorry to be pedantic but there’s no concept of Exception in JS). They just propagate it to the rejection channel. What was your precise experience?
- mstade 9y ago
  If there’s no logic to catch the rejection it will be silently ignored, which is effectively the same as “swallowing exceptions” – your distinction is correct but it’s academic at best. In practice, this behavior causes very real problems and in node land they made the sane decision to kill the process whenever an unhandled promise rejection comes about. I don’t know if this has landed yet, but you’ll see a warning about it if you run a node process in which you reject a promise.
  - rmrfrmrf 9y ago
    This was a problem before native Promises, but not so much anymore. Throwing on unhandledRejection has been the default in Node.js >= 7 and browsers now have DOM Levels 1 and 3 events for unhandledrejection.
    - mstade 9y ago
      This is a half truth. Native promises landed quite some time before a way to catch unhandled promises did, and even that event wasn’t enough, as evidenced by at least node deciding that the process needs to crash. (As it would’ve when unhandled exceptions were thrown.) The browser story is of course different. Regardless, the original poster was correct – this has been a sin of promises for a long time. What’s worse I think is that because of this we move have semantics that are close but not quite the same as exceptions. Case in point: throwing an exception while executing a promise function will reject the promise. But it’s not an exception anymore, even though the value of the rejection is in fact the exception. The semantics are now different – because promises. Promises in JavaScript have a certain almost-but-not-quite quality to them.
  - creatonez 9y ago
    Uncatched rejections are deprecated in Node.js. In a future version, an uncaught rejection will crash Node.js
    - mstade 9y ago
      Indeed, as I wrote in the second paragraph.
- amptorn 9y ago
  > there’s no concept of Exception in JS Sure there is. What else does the `throw` statement do, if not throw an exception?
  - rmrfrmrf 9y ago
    `throw` can throw anything. By convention, it throws Error objects.
    - lobster_johnson 9y ago
      "throw" takes the value to throw as an exception. An exception is an event which can be handled with "catch". [1] The standard refers to predefined errors such as TypeError as "exceptions". [1] http://www.ecma-international.org/ecma-262/6.0/#sec-try-statement http://www.ecma-international.org/ecma-262/6.0/#sec-try-stat...
    - amptorn 9y ago
      Sure, but "exception" is the programming term for that kind of behaviour. Saying "JavaScript has exceptions" doesn't imply that JavaScript has a global builtin object named `Exception` any more than saying "JavaScript has loops" implies that there's a global builtin object named `Loop` or `For`.
- lobster_johnson 9y ago
  Of course JS has exceptions. The EcmaScript explicitly uses the term "exception" [1]. [1] http://www.ecma-international.org/ecma-262/6.0/#sec-try-statement http://www.ecma-international.org/ecma-262/6.0/#sec-try-stat...

rictic 9y ago

Can you expand on that? How would an agent-based API propagate exceptions?

yuchi 9y ago

Promises don‘t swallow errors (sorry to be pedantic but there’s no concept of Exception in JS). They just propagate it to the rejection channel. What was your precise experience?

mstade 9y ago
If there’s no logic to catch the rejection it will be silently ignored, which is effectively the same as “swallowing exceptions” – your distinction is correct but it’s academic at best. In practice, this behavior causes very real problems and in node land they made the sane decision to kill the process whenever an unhandled promise rejection comes about. I don’t know if this has landed yet, but you’ll see a warning about it if you run a node process in which you reject a promise.
- rmrfrmrf 9y ago
  This was a problem before native Promises, but not so much anymore. Throwing on unhandledRejection has been the default in Node.js >= 7 and browsers now have DOM Levels 1 and 3 events for unhandledrejection.
  - mstade 9y ago
    This is a half truth. Native promises landed quite some time before a way to catch unhandled promises did, and even that event wasn’t enough, as evidenced by at least node deciding that the process needs to crash. (As it would’ve when unhandled exceptions were thrown.) The browser story is of course different. Regardless, the original poster was correct – this has been a sin of promises for a long time. What’s worse I think is that because of this we move have semantics that are close but not quite the same as exceptions. Case in point: throwing an exception while executing a promise function will reject the promise. But it’s not an exception anymore, even though the value of the rejection is in fact the exception. The semantics are now different – because promises. Promises in JavaScript have a certain almost-but-not-quite quality to them.
- creatonez 9y ago
  Uncatched rejections are deprecated in Node.js. In a future version, an uncaught rejection will crash Node.js
  - mstade 9y ago
    Indeed, as I wrote in the second paragraph.
amptorn 9y ago
> there’s no concept of Exception in JS Sure there is. What else does the `throw` statement do, if not throw an exception?
- rmrfrmrf 9y ago
  `throw` can throw anything. By convention, it throws Error objects.
  - lobster_johnson 9y ago
    "throw" takes the value to throw as an exception. An exception is an event which can be handled with "catch". [1] The standard refers to predefined errors such as TypeError as "exceptions". [1] http://www.ecma-international.org/ecma-262/6.0/#sec-try-statement http://www.ecma-international.org/ecma-262/6.0/#sec-try-stat...
  - amptorn 9y ago
    Sure, but "exception" is the programming term for that kind of behaviour. Saying "JavaScript has exceptions" doesn't imply that JavaScript has a global builtin object named `Exception` any more than saying "JavaScript has loops" implies that there's a global builtin object named `Loop` or `For`.
lobster_johnson 9y ago
Of course JS has exceptions. The EcmaScript explicitly uses the term "exception" [1]. [1] http://www.ecma-international.org/ecma-262/6.0/#sec-try-statement http://www.ecma-international.org/ecma-262/6.0/#sec-try-stat...