ref: Better UnhandledRejection messages

[kamilogorek]

Unfortunately, SyntheticExceptions are no-go, as promises just don't provide stack traces, even when Error objects manually create after the fact. It'll capture Tracekit global handler only, not original calls.

This change will most likely cause some events to re-appear with better messages for some of the clients.

---

Setup:

---

Before:

---

After:

---

It'd be nice to be able to show users some info regarding using Error objects for rejections, but I'm almost certain we shouldn't do this in the SDK. We already have all the data we need to do this in the UI (mechanism.type and mechanism.data.incomplete). Not sure about this change yet though, we can iterate.

[getsentry-bot]

	Warnings
⚠️	Please add a changelog entry for your changes.

	Messages
📖	✅ TSLint passed
📖	@sentry/browser bundle gzip'ed minified size: (ES5: 16.0566 kB) (ES6: 15.2588 kB)

Generated by 🚫 dangerJS against 7f2281c

[lobsterkatie]

I think this will be really helpful - thanks, @kamilogorek!

Question: if someone does this

class Dog { 
  constructor(name) {
    this.name = name;
  }
}

new Promise(() => {
  throw new Dog("Fido");
  // note: never throw your dog - it's mean
});

will that be handled the same way throw {plain: "object"} is?

[kamilogorek]

@lobsterkatie correct.

This would behave like error and have a stacktrace:

class Dog extends Error { 
  constructor(name) {
    super(name);
    this.name = name;
  }
}

new Promise(() => {
  throw new Dog("Fido");
  // note: never throw your dog - it's mean
});

[lobsterkatie]

Right, that makes sense. Thanks for the confirmation!