tc39 / proposal-error-stacks

ECMAScript Proposal, specs, and reference implementation for Error.prototype.stack / System.getStack
https://tc39.github.io/proposal-error-stacks/
MIT License
168 stars 13 forks source link

Add System.getStackFrames() #21

Closed AndreasMadsen closed 5 years ago

AndreasMadsen commented 6 years ago

String creation can often be computationally expensive and is not needed in some performance critical applications. Such applications are typically APM providers (stackman used by elastic-apm) and long-stack-trace (stack-chain used by trace).

I would suggest adding a System.getStackFrames() method, that only returns GetStackFrames(error).:

  1. If error does not have an [[ErrorData]] internal slot, throw a TypeError exception.
  2. Return ? GetStackFrames(error).
ljharb commented 6 years ago

This is basically already what System.getStack does: https://tc39.github.io/proposal-error-stacks/#sec-system-get-stack

except that it would return the "frames" property directly. String creation is already what all engines do - so I don't agree that it's prohibitively computationally expensive - and I'd also suspect that it's cheaper to make the string than to make the frames structure.

AndreasMadsen commented 6 years ago

except that it would return the "frames" property directly. String creation is already what all engines do - so I don't agree that it's prohibitively computationally expensive - and I'd also suspect that it's cheaper to make the string than to make the frames structure.

@ljharb It is certainly not the case in V8. I can't speak for any other engine as they don't provide the option.

ljharb commented 6 years ago

@AndreasMadsen since this proposal isn’t at stage 3 yet, it’s too early to have engines implement it. However, i suspect it’d be just as slow to gather the frame data as to prepare the string, since string operations are generally very fast. This is the sort of feedback I’d expect from implementors, and none of them mentioned anything in this realm so far (altho stage 3 would be the time to do it, and this is only at stage 1).

rdking commented 5 years ago

I know it's late in the game, but I just found out about this proposal. My 2 cents: I would hope that the frame data is available along side the strings. For those who want to process the strings, let them. But for others like myself, I would hope for a way to uniquely identify the run of a selected function. In general, I want to be able to detect that the current function (or the one N entries before the current) is a given function. I don't need to be able to access anything about that function beyond its identity (maybe using a Symbol specific to that function). Something like this is not presently possible using the simple strings currently provided from Error.stack()

ljharb commented 5 years ago

@rdking regardless, the frame data will be available. This issue is requesting a third API that provides the frame data by itself - ie, a shortcut to getStack(e).frames.

Being able to associate function references with the contents of a stack frame is both far, far beyond the scope of this proposal, and would likely be a very difficult follow-on.

rdking commented 5 years ago

Very difficult? Even if it's just a Symbol shoved into an internal slot of the function object that gets added as a property in each stack frame as the function id? Being able to ID a function was probably one of the best, yet least dangerous features of Function.caller. Tell me something, would maintaining a stack of such IDs really be all that difficult given that the execution contexts are also likely in a similar stack-like structure? I'm wondering if there is no value to having a global object that always grants access to stack frames (functions replaced with IDs of course).

ljharb commented 5 years ago

Either way, exploration of that is out of scope of this proposal, and not something I'll be pursuing.

ljharb commented 5 years ago

This seems answered.