18855 2008-05-02 14:42:28 -0700 Mechanism for storing line numbers and source URLs in JavaScript exceptions needs improvement 2014-12-17 16:52:44 -0800 1 1 1 Unclassified WebKit JavaScriptCore 523.x (Safari 3) Mac OS X 10.5 RESOLVED FIXED HasReduction, InRadar P2 Normal --- 1 ddkilzer webkit-unassigned ap burg ggaren joepeck levin oliver pmuellr rik zwarich oldest_to_newest 79485 0 ddkilzer 2008-05-02 14:42:28 -0700 * SUMMARY The mechanism for storing line numbers and source URLs for JavaScript exceptions fails to work in the following cases: - Throwing any non-object (like a string or a number) - Throwing any object with a property named "line" or a property named "sourceURL" What JavaScriptCore does now (in KJS::Node::handleException()) is to *modify* the exception object to add the "line" and "sourceURL" properties (but only if neither currently exist). It seems wrong to modify a JavaScript object simply to store metadata and obviously doesn't work if the exception is not an object. * STEPS TO REPRODUCE 1. Launch Safari/WebKit. 2. Open the Web Inspector. 3. Open one of the attached test cases. * RESULTS No line number or source URL is provided for the exceptions thrown in the test cases. * REGRESSION I don't think this is a regression. The code to set the "line" and "sourceURL" properties on the exception object existed as far back as r9352 in nodes.cpp. 79490 1 20932 ddkilzer 2008-05-02 14:59:37 -0700 Created attachment 20932 Test cases Additional fun facts: - Throwing an exception inside a function body from an onclick handler results in "undefined" for the description--always. - Throwing an object with just a "sourceURL" line will cause that URL to be printed in the Web Inspector. 79499 2 ddkilzer 2008-05-02 15:27:55 -0700 <rdar://problem/5908160> 168772 3 pmuellr 2009-12-04 08:15:11 -0800 It would be good to provide a set of tests to run across browsers to capture what everyone is doing here. Basically, something like Dave's tests that just run and produce results. But also include some of the existing 'built-in' exceptions, both thrown by existing internal code, as well as cons'd up by the user (eg, someone write's code that does a "throw new Error()") 714219 4 barraclough 2012-09-07 00:39:57 -0700 *** Bug 62897 has been marked as a duplicate of this bug. *** 878254 5 oliver 2013-04-18 23:20:02 -0700 The regular object and the primitive cases should work now. I think we are still deliberately deferring to properties on objects if there's a lineNo property 20932 2008-05-02 14:59:37 -0700 2008-05-02 14:59:37 -0700 Test cases bug-18855-test.html text/html 1007 ddkilzer PGh0bWw+CjxoZWFkPgo8c2NyaXB0PgpmdW5jdGlvbiB0ZXN0MCgpIHsKICAgIHRocm93KG5ldyBP YmplY3QoKSk7Cn0KZnVuY3Rpb24gdGVzdDEoKSB7CiAgICB0aHJvdyg0NSk7Cn0KZnVuY3Rpb24g dGVzdDIoKSB7CiAgICB0aHJvdygiTXlFeGNlcHRpb24iKTsKfQpmdW5jdGlvbiB0ZXN0MygpIHsK ICAgIEZvbyA9IGZ1bmN0aW9uKCkgewogICAgICAgIHRoaXMubGluZSA9IDk5OTsKICAgIH0KICAg IHRocm93KG5ldyBGb28oKSk7Cn0KZnVuY3Rpb24gdGVzdDQoKSB7CiAgICBGb28gPSBmdW5jdGlv bigpIHsKICAgICAgICB0aGlzLnNvdXJjZVVSTCA9ICJkYXRhOnRleHQvaHRtbCwlM2NiJTNlSGkl M2MvYiUzZSI7CiAgICB9CiAgICB0aHJvdyhuZXcgRm9vKCkpOwp9CmZ1bmN0aW9uIHRlc3Q1KCkg ewogICAgRm9vID0gZnVuY3Rpb24oKSB7CiAgICAgICAgdGhpcy5saW5lID0gOTk5OwogICAgICAg IHRoaXMuc291cmNlVVJMID0gImRhdGE6dGV4dC9odG1sLCUzY2IlM2VIaSUzYy9iJTNlIjsKICAg IH0KICAgIHRocm93KG5ldyBGb28oKSk7Cn0KPC9zY3JpcHQ+CjwvaGVhZD4KPGJvZHk+CjxidXR0 b24gb25jbGljaz0idGVzdDAoKSI+VGhyb3cgYW4gb2JqZWN0ICh3b3Jrcyk8L2J1dHRvbj48YnI+ CjxidXR0b24gb25jbGljaz0idGVzdDEoKSI+VGhyb3cgYSBudW1iZXI8L2J1dHRvbj48YnI+Cjxi dXR0b24gb25jbGljaz0idGVzdDIoKSI+VGhyb3cgYSBzdHJpbmc8L2J1dHRvbj48YnI+CjxidXR0 b24gb25jbGljaz0idGVzdDMoKSI+VGhyb3cgYW4gb2JqZWN0IHdpdGggYSAibGluZSIgcHJvcGVy dHk8L2J1dHRvbj48YnI+CjxidXR0b24gb25jbGljaz0idGVzdDQoKSI+VGhyb3cgYW4gb2JqZWN0 IHdpdGggYSAic291cmNlVVJMIiBwcm9wZXJ0eTwvYnV0dG9uPjxicj4KPGJ1dHRvbiBvbmNsaWNr PSJ0ZXN0MygpIj5UaHJvdyBhbiBvYmplY3Qgd2l0aCAibGluZSIgYW5kICJzb3VyY2VVUkwiIHBy b3BlcnRpZXM8L2J1dHRvbj48YnI+CjwvYm9keT4KPC9odG1sPgo=