
The Issues of Post-Mortem Debugging with Promises - fagnerbrack
https://www.joyent.com/blog/post-mortem-debugging-and-promises
======
heisenbit
The author is focusing on the server side but similar issues imho. are on the
client side too. I've recently stumbled into some reactive compiled TS code
while debugging and it became frustrating very quickly. The challenge to debug
async code is a hard one - at times it seems promises and observable may just
make easier to build a larger callback hell instance.

Besides the probably never fully granted wish of being able to replay
considering the standardization of these patterns is there anything we can do:

\- making the promise easier debug-able by changing the promise itself?

\- making the environment more supportive of debugging (approach like zone?)?

\- creating promise et. al. awareness in debuggers?

What are the existing best practices and how can we improve on them?

~~~
ingenter
From what I see, the only thing that can help with post-mortem debugging is
changing the promise so that it doesn't catch the exception when calling the
initialiser or handler. You can still do whatever you could with Promises (but
you have to do `Promise.reject(...)` or `reject(...)` instead of `throw ...`),
but it's not going to conform with the standard. Many libraries are probably
going to break if you drop-in a Promise implemented this way.

Edit: I didn't explain why this change is important: if the Promise is
catching the exception, the Execution Context where exception was thrown is
lost and (potentially) irrecoverable, the program has to crash there and now
if you want to debug the reason for the exception. This is a property of the
Promise standard, changes to debugging tools or environment won't help. You
could make Node aware of promises, and capture the execution context with
promise exception, but I don't think Promises are special enough.

