I have run into the following situation: a code refactoring I made introduced a TypeError, thrown by a caller that erroneously invokes an ES6 class constructor during inspector initialization. Unfortunately, the only error shown (with logging to console by stderr) is: file:///Users/burg/repos/webkit-dev/WebKitBuild/Release/WebInspectorUI.framework/Resources/Views/DataGrid.js:28:16: CONSOLE ERROR TypeError: Cannot call a class constructor Currently, ConsoleClient only captures a call stack for console messages with the "trace" type. So, the console only displays the first frame from the uncaught exception. The check that throws a TypeError is directly emitted into the constructor bytecode stream, which is what's seen here. But it's really the caller (next call frame) that we care about. So this seems to mostly be a problem associated with new ES6 errors with mysterious source locations. I propose two possible fixes, which are not mutually exclusive: * omit the call frame that's currently reported, since it is misleading to a user who is trying to debug the invalid call. * always capture/log multiple stack frames for uncaught exceptions, just like ConsoleClient does for "trace" messages. I welcome your thoughts on this issue prior to writing code.
<rdar://problem/22066390>
What I would probably do is remote debug the failed inspector with a known good inspector and then reload the failed inspector page.
Created attachment 260764 [details] reduced test case