Rethrow logic adds an extra stacktrace line which causes culprit to be set to raven.js

[tgr]

Steps to reproduce:

• install raven.js 1.1.16 with jQuery integration
• configure it to catch global errors via window.onerror
• throw an error in a function that gets wrapped (in my case, it was something called from a $.ready handler) and do not catch it manually

Expected result: culprit is the function which throws the error
Actual result: culprit is raven.js

Raw stack trace looks like this:

Stacktrace (most recent call first):

  at ? (/w/extensions/Sentry/resources/raven/raven.js:1282)
  at MultimediaViewer.MMVP.loadImage (/w/extensions/MultimediaViewer/resources/mmv/mmv.js:255:22)
  at Object.<anonymous> (/w/extensions/MultimediaViewer/resources/mmv/mmv.js:346:12)
  at Function.jQuery.extend.each (/w/load.php:383:23)
  at MultimediaViewer.MMVP.loadImageByTitle (/w/extensions/MultimediaViewer/resources/mmv/mmv.js:344:5)
  at Object.<anonymous> (/w/extensions/MultimediaViewer/resources/mmv/mmv.bootstrap.js:366:11)
  at Object.<anonymous> (/w/load.php:3276:33)
  at fire (/w/load.php:3119:30)
  at Object.self.fireWith [as resolveWith] (/w/load.php:3231:7)
  at MultimediaViewerBootstrap.MMVB.isCSSReady (/w/extensions/MultimediaViewer/resources/mmv/mmv.bootstrap.js:135:13)

Sentry report is at http://sentry-beta.wmflabs.org/jserrors/jserrors/group/14/

What seems to happen is that the wrapper rethrows the exception (this is line 195 of wrapped() in Raven.wrap()), that causes an extra line to be added to the stacktrace, and that line gets identified as the culprit.

This seems to be the combination of two bugs:

• raven.js not ignoring its own functions in the stack trace (If raven is the culprit, ignore that frame #200)
• the throw command gets added to the top of the stack, even though the exception is logged before it is rethrown. I suppose this is due to the TraceKit trickery of re-reporting the exception from the onerror handler to get more details in IE, but that should be completely unnecessary here (I was testing in Chrome 39).

[mattrobenolt]

I assume #200 would solve this as well, right? Since we'd just shift everything down the stack.

[tgr]

In most cases, it would. I am experimenting with using Sentry in an environment where all scripts get minified and bundled together, so I don't think there is any way to guess whether something is inside raven.js just from the stack trace (although that might depend on the browser, e.g. Chrome's stack trace API seems to provide direct access to the function objects in the stack so it could easily identify a custom function).

I guess the solution to that could be source maps and overriding the culprit on the server side.

[mattrobenolt]

This should be irrelevant now as well.