search

AndreasMadsen / trace

Creates super long stack traces
https://trace.js.org
MIT License
194 stars 18 forks source link

Treating error.stack as immutable? #44

Closed alcuadrado closed 5 years ago

alcuadrado commented 6 years ago

Hi Andreas,

As you may have seen here and here, if this proposal gets approved errors' stacks will be immutable. If that happens trace will need a redesign.

The main difference would be that the async-trace would have to be stored somewhere else, so printing a trace-enhanced stack trace will require special logic.

A default uncaughtException handler can be set by trace to print the complete errors in node, but special integrations with everything else will be needed. For example, mocha prints stack traces of tests that unexpectedly throw, and would need a trace integration to take advantage of it.

While this alternative design is not as cool as just adding -r trace in front of node, I think it's worth exploring if showing its usefulness can help v8's error-creation hook move forward and have a workable solution for async-traces.

AndreasMadsen commented 6 years ago

@alcuadrado From what I'm reading in the thread, it will still be possible to set [[ErrorData]] on Error construction. So that should be okay. Dealing with uncaughtException is going to be nasty, so I hope that won't be the case.

alcuadrado commented 6 years ago

I'm not that familiar with the last few versions of the EcmaScript standard, but this comment says that the proposal will forbid modifying [[ErrorData]].

But I read again the proposal, and if I understand correctly this will let you assign error.stack, circumventing the immutability of [[ErrorData]]. If this is correct this issue can be ignored as trace could still work.