4 ms·

I’d like to read more about the promise error handling thing, I’ve heard him/joyent mention that being a defect of promises but it’s not totally clear to me. I

I’d like to read more about the promise error handling thing, I’ve heard him/joyent mention that being a defect of promises but it’s not totally clear to me. I can also second the node async library not being amazing to work with. Before version 2.0 of the library, some of the functions (filter, detect, every) wouldn’t propagate errors.

bcantrill 9y ago
For whatever it's worth, I was actually referring to vasync[1], not async. The similar name is due to similar semantics (and in this regard, async inspired vasync), but vasync is very much designed around debuggability: you can couple it with the postmortem support we built into mdb for node.js[2] to be able to meaningfully debug seeming hung node programs from an operating system core. [1] https://github.com/joyent/node-vasync https://github.com/joyent/node-vasync [2] https://github.com/joyent/mdb_v8 https://github.com/joyent/mdb_v8
- rhinoceraptor 9y ago
  Yep, I was just responding to the "don't use async, use vasync" comment.
m1el 9y ago
Earlier this year I asked the exact same question. When I learned the answer, I was severely disappointed in JS Promises. You can read about that here: https://www.joyent.com/blog/post-mortem-debugging-and-promises https://www.joyent.com/blog/post-mortem-debugging-and-promis... https://gist.github.com/misterdjules/2969aa1b5e6440a7e401 https://gist.github.com/misterdjules/2969aa1b5e6440a7e401 Let me provide an example: asyncRequest().then(value => { var intermediateValue = 'foo'; return null.thisIsAnError; }).then(_ => console.log('success!'), err => console.log('error!', error)); This program contains a programmatic error, but Promises make it look like an operational error. Why is this bad? Because it prevents you from doing post-mortem debugging of your program. No matter what you do, you can't access intermediateValue after you noticed the error.. Promises catch all exceptions thrown inside callbacks, which makes debugging (especially post-mortem debugging) harder. I've personally encountered this problem.
- nailer 9y ago
  > No matter what you do, you can't access intermediateValue after you noticed the error.. Couldn't this be solved by dumping all values in the scope the exception was created? Ie this sounds like a VM feature request, rather than a limit of Promises.
  - m1el 9y ago
    This cannot be done the way you describe it. We already have VM features to inspect the scope of a function that failed. The problem is, Promises "handle" the exception, and prevent users from using this feature. I will repeat the statement: Promises catch exceptions thrown from handlers. This means that the scope in which the exception was thrown doesn't exist anymore.
    - nailer 9y ago
      [Small note: I'm trying to learn here, that's all] I still don't understand. When a Promise throws an exception and we catch() it (assuming 'await' here as I've never used Promises with .then() for anything serious), couldn't the err passed to the catch() expose the necessary parts of the scope like it could for exceptions not created by Promises?
      - m1el 9y ago
        > couldn't the err passed to the catch() expose the necessary parts of the scope like it could for exceptions not created by Promises? That would require Promises to create and use a new unique and intrusive API into the interpreter. Requiring an exception to preserve the scope in some specific case is... problematic, to say the least. Instead exceptions in Promise callback could be handled as uncaught exceptions, which would solve the problem caused by Promises catching all exceptions and passing them as error values.
        nailer 9y ago
        Thanks for replying. > Requiring an exception to preserve the scope in some specific case is... problematic, to say the least. I was thinking about having exceptions preserve scope in all cases, or in all cases if a flag is turned on. I don't quite understand what the difference is between `catch(error)` when using await/promises and `catch(error)` when doing something else. Is the main concern here the overhead?

bcantrill 9y ago

For whatever it's worth, I was actually referring to vasync[1], not async. The similar name is due to similar semantics (and in this regard, async inspired vasync), but vasync is very much designed around debuggability: you can couple it with the postmortem support we built into mdb for node.js[2] to be able to meaningfully debug seeming hung node programs from an operating system core. [1] https://github.com/joyent/node-vasync https://github.com/joyent/node-vasync [2] https://github.com/joyent/mdb_v8 https://github.com/joyent/mdb_v8

rhinoceraptor 9y ago
Yep, I was just responding to the "don't use async, use vasync" comment.

m1el 9y ago

Earlier this year I asked the exact same question. When I learned the answer, I was severely disappointed in JS Promises. You can read about that here: https://www.joyent.com/blog/post-mortem-debugging-and-promises https://www.joyent.com/blog/post-mortem-debugging-and-promis... https://gist.github.com/misterdjules/2969aa1b5e6440a7e401 https://gist.github.com/misterdjules/2969aa1b5e6440a7e401 Let me provide an example: asyncRequest().then(value => { var intermediateValue = 'foo'; return null.thisIsAnError; }).then(_ => console.log('success!'), err => console.log('error!', error)); This program contains a programmatic error, but Promises make it look like an operational error. Why is this bad? Because it prevents you from doing post-mortem debugging of your program. No matter what you do, you can't access intermediateValue after you noticed the error.. Promises catch all exceptions thrown inside callbacks, which makes debugging (especially post-mortem debugging) harder. I've personally encountered this problem.

nailer 9y ago
> No matter what you do, you can't access intermediateValue after you noticed the error.. Couldn't this be solved by dumping all values in the scope the exception was created? Ie this sounds like a VM feature request, rather than a limit of Promises.
- m1el 9y ago
  This cannot be done the way you describe it. We already have VM features to inspect the scope of a function that failed. The problem is, Promises "handle" the exception, and prevent users from using this feature. I will repeat the statement: Promises catch exceptions thrown from handlers. This means that the scope in which the exception was thrown doesn't exist anymore.
  - nailer 9y ago
    [Small note: I'm trying to learn here, that's all] I still don't understand. When a Promise throws an exception and we catch() it (assuming 'await' here as I've never used Promises with .then() for anything serious), couldn't the err passed to the catch() expose the necessary parts of the scope like it could for exceptions not created by Promises?
    - m1el 9y ago
      > couldn't the err passed to the catch() expose the necessary parts of the scope like it could for exceptions not created by Promises? That would require Promises to create and use a new unique and intrusive API into the interpreter. Requiring an exception to preserve the scope in some specific case is... problematic, to say the least. Instead exceptions in Promise callback could be handled as uncaught exceptions, which would solve the problem caused by Promises catching all exceptions and passing them as error values.
      - nailer 9y ago
        Thanks for replying. > Requiring an exception to preserve the scope in some specific case is... problematic, to say the least. I was thinking about having exceptions preserve scope in all cases, or in all cases if a flag is turned on. I don't quite understand what the difference is between `catch(error)` when using await/promises and `catch(error)` when doing something else. Is the main concern here the overhead?