3 ms·
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:
by 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 agoThis 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 agoThanks 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?