The Issues of Post-Mortem Debugging with Promises

joyent.com

3 points·fagnerbrack··2 comments

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?

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.

Reply on news.ycombinator.com