[Webkit-unassigned] [Bug 167934] New: Rethrowing error resets stack trace making debugging hard

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=167934

            Bug ID: 167934
           Summary: Rethrowing error resets stack trace making debugging
                    hard
    Classification: Unclassified
           Product: WebKit
           Version: Safari 10
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: malteubl at google.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170207/e4419b60/attachment.html>