Experiment: Thrown errors passing through startSpan should be associated with first passed through span

[lforst]

Description

Today, an error is only associated with the span that was active at the time captureException(err) was called. This leads to interesting situations like the following:

function foo() {
  startSpan({ name: "foo" }, () => { // <-- Error will be associated with this span, even though it was thrown in the "bar" span
    try {
      bar();
    } catch (e) {
      captureException(e);
    }
  });
}

function bar() {
  startSpan({ name: "bar" }, () => {
    throw new Error();
  });
}

We could experiment with adding a try-catch to the startSpan wrappers that writes a non-enumerable span ID to errors that pass through (if they didn't have one yet), which is then picked up and preferred by the error processing pipeline over the span ID that is on the scope.

[Lms24]

I think this is worthwhile and we should just give it a try. As we discussed offline, there's this bigger picture concern of scope data in general (i.e. the active span is also just the span active on the scope) being lost if you don't manually call captureException within the scope's closure.

I found the GH issue where we discussed this on a cross-sdk level: getsentry/sentry-python#2857

The gist is: Technically, we're correct in not appyling any scopes for uncaught or outside-closure-caught errors. It is however unexpected behaviour for a lot of users.

So I'd say we just do it for the span id, see how that is received and learn from it!