h: I think this will change how the dom exceptions are classified, I pushed a test to see if it would pass.

Maybe something like this would keep the best of both worlds here, could you try something like:

// same check as before
if ('stack' in (exception as Error)) {
  event = eventFromError(stackParser, exception as Error);

  // preserves the classification while adding stacktraces if it exists...
  const firstException = event.exception?.values?.[0];
  if (attachStacktrace && syntheticException && firstException && !firstException.stacktrace) {
    const frames = parseStackFrames(stackParser, syntheticException);
    if (frames.length) {
      firstException.stacktrace = { frames };
      addExceptionMechanism(event, { synthetic: true });
    }
  }
} else {
  // existing fallback
}

Contradictory test expects wrong branch behavior

Medium Severity

The test "preserves DOMException type when stack is an empty string" expects type: 'SyntaxError' and value: 'The string did not match the expected pattern.', but it has the same setup as the test at line 172 (stack = '', attachStacktrace = true), which expects type: 'Error' and value: 'SyntaxError: The string did not match the expected pattern.'. Tracing through the production code, the empty stack takes the eventFromString path, producing type: 'Error' and the combined name: message value. This test's expectations reflect the old eventFromError path behavior and will fail.

 

^{Reviewed by Cursor Bugbot for commit 83ae1e5. Configure here.}

This works against today's implementation, I'm just ensuring we lock it in and see if this PR changes it.

DOMException type classification lost for empty stack traces

Medium Severity

Changing the check from 'stack' in (exception as Error) to a truthy check causes DOMExceptions with empty stack strings to fall into the else branch, which uses eventFromString + addExceptionTypeValue. This loses the specific DOMException type (e.g., 'SyntaxError', 'NotAllowedError') and replaces it with a generic 'Error' type, because addExceptionTypeValue defaults the type to 'Error'. The exception value also changes from just the message to a name: message format. This regression in error classification will affect how users group and identify DOMException errors in Sentry. The contradictory test at line 190 (expecting type: 'SyntaxError') confirms this is a recognized problem — it will fail because the code actually produces type: 'Error'.

 

^{Reviewed by Cursor Bugbot for commit 901e3ef. Configure here.}