Bug 167934 – Rethrowing error resets stack trace making debugging hard

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: JavaScriptCore

[Malte Ubl]

In JavaScript it is common to rethrow errors when they cannot immediately be handled. Here is some example code:

try {
  mayThrow();
} catch (e) {
  if (e.message == 'something I can handle') {
    handleError(e);
  } else {
    throw e;
  }
}

When executed in JavaScriptCore the error object created in the try block gets a new stack trace when it is rethrown. While there are situations when that might be desirable in the vast majority of cases it is not. Especially in this common pattern:

try {
  mayThrow();
} catch (e) {
  // Don't interrupt execution flow, but do report error.
  setTimeout(function() {
    throw e;
  });
}

Java solves this my making stack traces a linked list of places an exception haa been thrown. Since this is not available in JS, one must choose, and choosing the original location is better in the vast majority of cases.

Here is a full repro case:
http://output.jsbin.com/lufeqe/quiet

Compare the console output between V8 and JavaScriptCore. In V8 it is immediately obvious what happened, while JSC provides no useful information for 2 of the 3 errors.

[Radar WebKit Bug Importer]

<rdar://problem/30433531>

[Frédéric Wang (:fredw)]

Testing in Firefox, it seems that SpiderMonkey behaves the same as V8.

[Frédéric Wang (:fredw)]

Created attachment 314702 [details]
Testcase (console output)

[Frédéric Wang (:fredw)]

Created attachment 314703 [details]
Testcase (print stack trace)

[Frédéric Wang (:fredw)]

Created attachment 314704 [details]
Testcase (to run in JSC)

[Frédéric Wang (:fredw)]

The stack trace of attachment 314704 [details] seems correct using JSC (TOT):

WebKitBuild/Release/bin/jsc -e "`curl https://bug-167934-attachments.webkit.org/attachment.cgi?id=314704`"
Stack of an exception:
throwError@[Command Line]:2:18
caller@[Command Line]:6:13
invokee@[Command Line]:10:9
root@[Command Line]:14:10
global code@[Command Line]:19:7

Stack of a rethrown exception:
throwError@[Command Line]:2:18
caller@[Command Line]:6:13
invokee@[Command Line]:10:9
root@[Command Line]:14:10
global code@[Command Line]:28:9

Similarly, opening attachment 314703 [details] in MiniBrowser (TOT) the exception stack trace are correctly printed in the textarea.

Attachment 314702 [details] is similar to the original test case (i.e. using separate script tags and checking the console) and indeed shows that the stack incorrect for the rethrown exception. Again, using TOT.

[Frédéric Wang (:fredw)]

Created attachment 314706 [details]
Testcase (console output, only the rethrown error)

This is a simplified version of attachment 314702 [details] with only the rethrown exception and using only one <script> tag. It still exhibits the issue in MiniBrowser.

[Caitlin Potter (:caitp)]

Quick design for a fix:

1. In `JSC::Exception::create(VM&, JSValue);`:
If thrownValue inherits ErrorInstance, and does not have a captured stacktrace already, store the captured stacktrace on it (private symbol, or member of ErrorInstance).

2. In createScriptCallStackFromException() (ScriptCallStackFactory.cpp):
If exception->value() is an instance of ErrorInstance, load the stacktrace symbol,
and use it to assemble the ScriptCallStack

Console API adds the message like usual, and it should include the originally thrown stacktrace (provided the thrown object inherits(ErrorInstance::class())).

---

This seems to more or less match the behaviour of Chromium, so although there are caveats, I don't know that anyone has found that behaviour problematic in Chromium yet.

[Caitlin Potter (:caitp)]

Prototype patch in bug 174380

[Frédéric Wang (:fredw)]

(In reply to Frédéric Wang (:fredw) from comment #6)
> The stack trace of attachment 314704 [details] seems correct using JSC (TOT):
> ...
> Similarly, opening attachment 314703 [details] in MiniBrowser (TOT) the
> exception stack trace are correctly printed in the textarea.

Just to follow-up here. These test cases print Error.stack which is indeed the one requested in this bug report. Hence they can not exhibit the issue, contrary to the test cases requiring the use of the Web Inspector.

It turns out that the Web Inspector prints the Exception object's stack (and does it on purpose), which indicates the location of when that exception was last (re)thrown and hence does not correspond to the behavior Chromium or Firefox's console.

For details and ideas see the discussion on bug 174380.

[Frédéric Wang (:fredw)]

Comment on attachment 314703 [details]
Testcase (print stack trace)

This testcase won't allow to reproduce the issue per comment 10.

[Frédéric Wang (:fredw)]

Comment on attachment 314704 [details]
Testcase (to run in JSC)

This testcase won't allow to reproduce the issue per comment 10.

[Saam Barati]

Looking into this now

[Saam Barati]

It seems like all action is in https://bugs.webkit.org/show_bug.cgi?id=174380

Do we need two bugs for the same thing?

[Saam Barati]

*** This bug has been marked as a duplicate of bug 174380 ***