async stack traces

[nayeemrmn]

(async () => {
  await Promise.resolve().then(() => {
    const error = new Error;
    console.log(error.stack);
    throw error;
  });
})();

Error: 
    at file:///mnt/c/Users/Nayeem/projects/deno/temp.js:3:19
    at async file:///mnt/c/Users/Nayeem/projects/deno/temp.js:2:3
error: Uncaught Error
    at file:///mnt/c/Users/Nayeem/projects/deno/temp.js:3:19

This is very important. It prevents error stack traces for asynchronous ops from reaching the faulting user code.

[ry]

Ref https://docs.google.com/document/d/13Sy_kBIJGP0XT34V1CV3nkWya4TwYx9L3Yv45LdGB6Q/edit
nodejs/node#11865

[nayeemrmn]

The was also the constructor issue:

class DenoError extends Error {
  constructor() {
    super();
  }
}

const error = new DenoError;
console.log(error.stack);
throw error;

Error: 
    at file:///mnt/c/Users/Nayeem/projects/deno/temp2.js:7:15
error: Uncaught Error
    at DenoError (file:///mnt/c/Users/Nayeem/projects/deno/temp2.js:3:5)
    at file:///mnt/c/Users/Nayeem/projects/deno/temp2.js:7:15

Ref https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error#Custom_Error_Types

There seem to just be general discrepancies between error.stack and the automatically printed one, as if the latter is being populated using outdated logic. Might be a quick fix in that case but the whole thing is very weird.

[ry]

@Nayeem-Rahman let's handle that one separately in #2710 ... I suspect there are two different problems, and #2710 is easier.

[nayeemrmn]

Okay, two stack traces are captured by ErrorUtils::Construct() whenever an error is constructed:

The first is captured by Isolate::CaptureAndSetDetailedStackTrace() and is stored in the exception under the symbol factory()->detailed_stack_trace_symbol().

The second is captured by Isolate::CaptureAndSetSimpleStackTrace() and is stored in the exception under the symbol factory()->stack_trace_symbol().

• The first one is bad. It uses Isolate::CaptureCurrentStackTrace(), which clearly sets options.async_stack_trace to an unconditional false and doesn't determine a FrameSkipMode using error constructor information. This is the one that's printed on abort according to this stack:

  • factory()->detailed_stack_trace_symbol() is read by
  • Isolate::GetDetailedStackTrace() which is called by
  • Isolate::CreateMessage() which is called by
  • Exception::CreateMessage() which is called by
  • EncodeExceptionAsJSON() which deno uses.

• The second one uses Isolate::CaptureSimpleStackTrace(), which respects the flags and accepts a FrameSkipMode that gets passed down from the error constructor. This is the one that error.stack points to: Accessors::ErrorStackGetter(). However, this gets replaced with a stringified version of itself here so the FixedArray of frames is lost.

[bartlomieju]

Done in #2820?

[nayeemrmn]

Done in #2820?

@bartlomieju No, that just ensures DenoErrors aren't constructed in the message handler so their call stack includes user code.

This is about the stack trace printed by Deno when aborting on an uncaught error. The one we currently get from V8 isn't the same one that error.stack uses, it doesn't include async frames and another problem described in #2710. Turns out V8 captures two different stacks traces with two different sets of rules.

@ry These should be one issue: Use the same stack trace as error.stack when aborting. Node and Chrome definitely do.